When I wrote this code, I thought this array would usually be so short
that indexOf would be faster than Set.prototype.has, but of course the
pathological cases are what end up mattering, and I've recently seen some
result objects that cause thousands of shallow copies to be made over a
series of many merges using one DeepMerger instance.

Since shouldInclude gets called for every single field in any read or
write operation, it's important that it takes any available shortcuts to
handle the common case (no directives) as cheaply as possible.

Since any of the provided variables could be consumed by any of the fields
in a selection set that we're reading, all variables are potentially
relevant as part of the result object cache key, so we don't make any
attempt to stringify just a subset of the variables. However, since we use
the same stringified variables in every cache key, there's no need to
perform that encoding repeatedly. JSON.stringify may be fast, but the
variables object can be arbitrarily large.

Believe it or not, iterating over the values of policies.rootTypenamesById
was noticeably expensive according to Chrome devtools profiling. Since
this information almost never changes, we might as well maintain it in the
format that's most convenient.

Creating a throwaway array just to call JSON.stringify was much more
expensive than string concatenation. The exact format of these cache keys
is an invisible implementation detail, so I picked something that seemed
unlikely ever to be ambiguous, though we can easily change it later.

Since policies.applyMerges doesn't change anything unless there are custom
merge functions to process, we can skip calling it if no merge functions
were found while processing the current entity.

Instead of recursively calling processSelectionSet to handle fragments, we
can simply treat their fields as fields of the current selection set.

This change means fragment results will no longer be cached separately
from normal selection set results, which is potentially a loss of caching
granularity, but there's also a reduction in caching overhead because
we're caching fewer result objects, and we don't have to merge them all
together, and (most importantly) the result caching system still tracks
dependencies the same way as before.

It's as if we transformed the query by inlining fragment selections,
except without doing any work!

Although this may seem like a reversion to forEach instead of a for loop,
the for loop had an unexpectedly negative impact on minification, and a
Set has the ability to deduplicate selection objects, so we never
re-process the same field multiple times through different fragments.

#5948 (comment)