feat(gatsby): PQR: merge data dependencies from workers to the main process

[vladar]

Description

We need to sync parts of the build state from the query worker to the main process. This PR "replays" selected actions from workers in the main process when each query chunk is finished.

The alternative approach would be to merge state at the end of query running but this may be error-prone and harder to maintain because requires that each reducer interested in query events additionally "knows" about this potential merge step.

The upside of state merging is that it can be more performant and has less IPC communication overhead. So we may get back to it eventually if action replaying proves to be too expensive.

[ch33833]

[pieh]

Just so there is papertrail on PR:

keep in mind PAGE_QUERY_RUN action now is dispatched in workers and we would need it in main process to keep track of static query results chaging for incremental html builds in

gatsby/packages/gatsby/src/redux/reducers/html.ts

Lines 91 to 120 in 54ed0c3

	case `PAGE_QUERY_RUN`: {
	// Despite action name, this action is actually emitted for both page and static queries.
	// In here we actually only care about static query result (particularly its hash).
	// We don't care about page query result because we don't actually use page query result
	// directly when generating html. We care about page-data (which contains page query result).
	// Handling of page-data that transitively handles page query result is done in handler for
	// `ADD_PAGE_DATA_STATS` action.
	if (!action.payload.isPage) {
	// static query case
	let staticQueryResult = state.trackedStaticQueryResults.get(
	action.payload.queryHash
	)
	if (!staticQueryResult) {
	staticQueryResult = {
	dirty: FLAG_DIRTY_STATIC_QUERY_FIRST_RUN,
	staticQueryResultHash: action.payload.resultHash,
	}
	state.trackedStaticQueryResults.set(
	action.payload.queryHash,
	staticQueryResult
	)
	} else if (
	staticQueryResult.staticQueryResultHash !== action.payload.resultHash
	) {
	staticQueryResult.dirty |= FLAG_DIRTY_STATIC_QUERY_RESULT_CHANGED
	}
	}
	return state
	}

[vladar]

Yeah, after some thinking I've changed the implementation to just replaying actions after each chunk is done. If data dependencies will be too expensive to sync this way - we can do a hybrid approach - forward/replay some actions and merge expensive parts all at once in the end.

But first, let's try the simple approach with just replaying actions.

[LekoArts]

Two smaller nits