POC: Implement Multi fetch

[alexus37]

• related to Router executed multiple requests to same subgraph to resolve entities wundergraph/cosmo#1300

This pull request introduces several significant enhancements to the post-processing capabilities of the graphql-go-tools package, specifically in the management of fetch tree nodes. The key modifications include the introduction of a new Multi fetch tree node type, updates to the loader to accommodate this new node type, and the addition of corresponding test cases to verify the functionality of these enhancements.

The rationale behind this change is to alleviate the load on a subgraph when a router resolves a query. The primary objective is to consolidate multiple requests, which typically execute in parallel, into a single "Multi" request.

This approach represents a trade-off between capacity and performance.

The overall implementation is executed in a two-step process:

1. A new post-processor is introduced that analyzes the fetch tree and generates new "Multi" nodes for fetches that can be combined.
2. A new loader is implemented to manage these "Multi" nodes and construct the necessary query.

The Multi Node Post Processor

This post-processor analyzes parallel nodes and generates multi nodes for all Entity or Batch Entity fetches directed to the same data source (subgraph).

The Multi Loader

This loader operates in a two-step manner: first, it utilizes all the fetches to create a Multi request using aliases; second, it disentangles the response into the appropriate paths for each fetch.

For example, two fetches like this would be combined into a single Multi fetch:

query($representations: [_Any!]!) {
_entities(representations: $representations) {
	... on Product {
		__typename
		otherField
	}
}

query($representations: [_Any!]!) {
_entities(representations: $representations) {
	... on User {
		__typename
		someField
	}
}

Result:

query MultiFetch($f_1representations: [_Any!]!, $f_2representations: [_Any!]!) {
f_1:
		_entities(representations: $f_1representations) {
			... on Product {
				__typename
				otherField
			}
		}
f_2:
		_entities(representations: $f_2representations) {
			... on User {
				__typename
				someField
			}
		}
}

Limitations and Future Work

I would like to emphasize that this is a proof of concept (PoC) and that several adjustments are necessary for proper implementation:

1. The post processor should ideally generate the correct multi-fetch query string.
2. Instead of using string concatenation, we should utilize variable rendering.
3. Currently, only entity and batch entity fetches are supported; we should consider adding support for single fetches as well.
4. More advanced merging. Eg. if two requests ask for the the same entity type with the same attributes this can be merged in to a single aliased request.
5. Look into request skipping, this is currently not supported
6. Most likely much more :)

[jensneuse]

You can add an additional post processing step that replaces a Parallel Node in the root with the child if the child length is 1.