Improve optimistic update performance by limiting cache key diversity.

[benjamn]

This PR restores the full benefits of result caching (#3394) when optimistic updates are pending, which should significantly improve the performance of optimistic updates. Apollo Client 2.x did not attempt to apply result caching to optimistic data, and the EntityStore (fka EntityCache; see #5618) introduced by Apollo Client 3.0 has been getting the cache key logic slightly wrong since it was first implemented, so the problem addressed by this PR falls somewhere between a bug and an optimization opportunity.

Details can be found in the commit messages, reproduced here:

Divide EntityStore into optimistic and non-optimistic CacheGroups

The result caching system introduced by #3394 gained the ability to cache optimistic results (rather than just non-optimistic results) in #5197, but since then has suffered from unnecessary cache key diversity during optimistic updates, because every EntityStore.Layer object (corresponding to a single optimistic update) counts as a distinct cache key, which prevents cached results from being reused if they were originally read from a different Layer object.

This commit introduces the concept of a CacheGroup, store.group, which manages dependency tracking and also serves as a source of keys for the result caching system. While the Root object has its own CacheGroup, Layer objects share a CacheGroup object, which is the key to limiting diversity of cache keys when more than one optimistic update is pending.

This separation allows the InMemoryCache to enjoy the full benefits of result caching for both optimistic (Layer) and non-optimistic (Root) data, separately.

Implement EntityStore#makeCacheKey to simplify result caching

Although all the components of a key returned by makeCacheKey are important, there's usually one that "anchors" the rest, because it survives the longest and changes the least. In the case of the result caching system, the current EntityStore object is that anchor.

This commit formalizes that anchoring role by making the EntityStore literally responsible for generating cache keys based on query AST objects, variables, and other frequently changing inputs.

Especially given the recent introduction of CacheGroup logic, it's easier to reason about the makeCacheKey functions if we put part of their implementation behind an abstraction. This abstraction also means we no longer need to pass a KeyTrie into the StoreReader constructor, as the KeyTrie (context.store.group.keyMaker) now resides within the EntityStore, which is provided to StoreReader as part of the ExecContext (context.store).

[hwillson]

Very interesting solution @benjamn (and thanks for explaining the cache key diversity issue so clearly!).