Includes updates to the `apollo-utilities` package to better
accommodate Apollo Client's local state handling capabilities.

- Adds a new transform `buildQueryFromSelectionSet' function to
  help construct a GraphQL Query from a Mutation selection set.
- Adds a new transform `removeClientSetsFromDocument` function
  to prune `@client` selection sets and fields from GraphQL
  documents'.
- Adds a new directive based `hasClientExports` function to see
  if a GraphQL document is using a `@client @export` directive
  combination.
- Adds a new `mergeDeep` utility function for deep cloning.

When using the `@client` directive, it might be desirable in
some cases to want to write a selection set to the store,
without having all of the selection set values available.
This is because the `@client` field values might have already
been written to the cache separately (e.g. via Apollo
Cache's `writeData` capabilities). Because of this, we'll
skip the missing field warning for fields with `@client`
directives.

This is a temporary change, while working on the local state
alpha changes.

This commit provides the bulk of the new Apollo Client local
state handling capabilities. It replaces the need to use
`apollo-link-state` in a link chain for local state management,
by merging local state handling directly into the Apollo Client
core. The majority of the new local state functionality can be
found in the `LocalState` class, which is tied into the
`QueryManager` to integrate with Queries, Mutations and
Subscriptions.

Key Changes:

- Replaces the need to use `apollo-link-state`.
- `apollo-link-state` defaults have been replaced with new
  initializer functions, which are a much more capable and
  flexible way to initialize the cache.
- Initializers and local resolvers can be set through the
  `ApolloClient` constructor, or set separately using new
  public API functions.
- A local schema can be set through `ApolloClient`, which
  can then be used by external tooling (like Apollo Client
  Devtools).
- Mixing remote and local (`@client` based) data together in
  queries is supported.
- Queries can now use the `@export` directive to export the
  result of a local resolver into a variable, that can then
  be automatically passed into a subsequent query. E.g.
  `@client @export(as: "someVar")`
- Full SSR support.
- Numerous bug fixes made to address the oustanding
  `apollo-link-state` issue backlog.

Various tests to cover Apollo Client local state handling.

Remove Boost's dependency on `apollo-link-state`, and wire it up
with AC's local state functionality.

By default, local resolvers are controlled by a query's
`fetchPolicy`. If a query that has configured local
resolvers is run with a fresh cache, and that query is
using `ApolloClient.query`'s default `fetchPolicy` of
`cache-and-network`, the local resolvers will be fired
and the result will be stored in the AC cache. If the
same query fires again however, since the query result
already exists in the cache, it will be loaded and used
instead of firing the query's local resolvers again. This
functionality can be altered by using a `fetchPolicy` of
`no-cache` for example, but setting a `fetchPolicy` impacts
an entire query. So if mixing local and remote results and
using a `fetchPolicy` of `no-cache`, local resolvers will
always run, but so will the fetch to retrieve network
based data.

To address this, AC's local state functionality includes
a new `resolverPolicy` approach. Setting a `resolverPolicy`
of `resolver-always` makes sure local resolvers are
always fired for a query, on every request. While this
approach works, it is inflexible due to the fact that
it does not provide a way to only always run certain local
resolvers associated with a query, instead of running all
of them. Apollo Client's `fetchPolicy` approach has also
historically demonstrated that getting `fetchPolicy` settings
right can be a bit tricky (especially for newcomers to the
Apollo ecosystem), so adding another configurable policy
based approach is not overly desirable.

The changes in this commit remove the `resolverPolicy`
functionality. They then ensure that fields marked with
`@client(always: true)` always have their local resolvers
run, on each request. This provides a way to control
exactly which parts of a query should have its local
resolvers always run, and which parts can continue to
leverage the cache.

Technical side note: when using `@client(always: true)`,
the full query will be resolved from the cache first,
before any local resolvers are run. So if data already
exists in the cache for a field that's marked with
`@client(always: true)`, it's loaded first as part of
reading the fully executed query from the cache (including
local and remote results). That data (if it exists) is
then overwritten by the result from the associated local
resolver, and returned as part of the query result. This
load then override approach makes sure that the integrity
of the cache is not affected by running local resolvers.

The QueryManager#stop method cancels all pending fetches by running
this.fetchQueryRejectFns. However, this leads to some unhandled promise
rejections during tests, which might go unnoticed because they don't cause
the test suite to fail.

This commit makes the QueryManager#stop method a bit more aggressive about
stopping active queries and unsubscribing from observables, which prevents
the unhandled rejections.

…oroughly

Prevent unhandled rejections by stopping QueryManager more thoroughly.

This reverts commit 9739ff6.

Now that we have a uniform interface for terminating ApolloClient
instances (#4336), there should be no need for any external code to access
the QueryScheduler abstraction, which this commit removes.

We should wait to merge and release this change until after
apollographql/react-apollo#2741 has been merged
and released, so that we don't break older versions of MockedProvider.

…removal

Un-revert "Improve (and shorten) query polling implementation. (#4243)"

Running

  tsc -p tsconfig.test.json --noEmit

in the apollo-client/packages/apollo-client directory produced a number of
warnings and errors before this commit (tsc version 3.2.2).

By relying on normal promise rejection, we can avoid needing the onError
callback parameter.

Removing await expressions in favor of explicit promises tends to save a
small amount of bundle size. It's still a good idea to keep runResolvers
async, because async functions reliably capture any exceptions thrown
during the execution of the function.

Besides removing await expressions, this commit performs a single
mergeDeepArray instead of multiple binary mergeDeep calls.

This type was already quite different from the GraphQLResolveInfo type
used by the GraphQL specification, so I think we should limit it to just
the necessary information while we still have that freedom:
https://graphql.org/learn/execution/#root-fields-resolvers

If a resolver needs them, the { isLeaf, resultKey, directives } data
previously provided can all be derived from the FieldNode.

On the surface, the idea of using initializers as a way to
dynamically prep the cache seemed like a good idea. It was a
more flexible way to initiliaze the cache than the `defaults`
approach `apollo-link-state` uses. In practice however,
everything `initializers` can do `cache.writeData` can do as
well. Yes initializers are a little more user friendly to work
with, but `cache.writeData` is already part of the cache API and
is much more flexible in terms of being able to be called anywhere
the cache is available, and it's explicit in what it's doing.
Given this, we've decided to remove initializer support from
Apollo Client, keeping the local state changes focused on the
idea of running local resolvers.

While prepping the cache is still an important peice of
functionality, we'll update the local state docs to show how
`cache.writeData` can be used to handle everything
`initializers` were being used for, including re-initializing
the cache after a store reset.

Removing initializers also has the added benefit of reducing
the Apollo Client bundle size by a good chunk.

The LocalState#runResolvers method now requires a remoteResult option of
type ExecutionResult<TData> and returns a Promise<ExecutionResult<TData>>,
and this contract is enforced (somewhat better) using generic types.

Since the new local state changes will be rolled out in a minor
release, we have to make sure Boost local state support is
backwards compatible. To do this, this commit adjusts the
`clientState` parameter approach such that if `defaults` are
passed in, they are automatically written to the cache using
`cache.writeData`. Also, the Boost constructor has been updated
to line up with the new `ApolloClient` constructor changes,
meaning `resolvers`, `typeDefs`, and `fragmentMatcher` can now
be passed into the Boost constructor.

Other than making sure Boost doesn't break when the local state
changes are rolled out, we won't be making other Boost changes.
Apollo Boost is still slotted for deprecation in AC 3.0.

We're going to avoid getters/setters for `typeDefs` for now,
and instead recommend `typeDefs` are set via the `ApolloClient`
constructor. We were originally exposing getters/setters for
integrations like Apollo Client Devtools, but we'll adjust
devtools to access the `typeDefs` in a different way. We will
likely want to revisit this decision in the future, to
accommodate the possibility that people want to add to their
local schema at different points in their application, but
we'll cross that bridge when we get there. For now keeping the
changes to the public `ApolloClient` API minimal, is the goal.

Apollo Client integrated local state handling

 - apollo-boost@0.3.0-beta.0
 - apollo-cache-inmemory@1.5.0-beta.0
 - apollo-cache@1.2.0-beta.0
 - apollo-client@2.5.0-beta.0
 - apollo-utilities@1.2.0-beta.0
 - graphql-anywhere@4.2.0-beta.0

To create this commit, I (@benjamn) first squashed all of @rosskevin's
commits from PR #4261 into one big commit, then reverted any changes that
did not seem essential to the new bundling strategy discussed in that
PR. Once that was done, I rebased against origin/release-2.5.0 and fixed
the conflicts. With a few more minor tweaks, all tests are passing.

I will push a few additional changes after this commit, but I wanted to
preserve @rosskevin's intentions as much as possible here, since his name
is still attached to this commit.

Type checking should respect the local tsconfig.json file within each package.

Mixing default and named imports causes Rollup to use both, which leads to
slightly more generated code, on the whole.

Revamp CJS and ESM bundling with Rollup (extracted from #4261)

Now with support for production-strippable invariant.warn(...) and
invariant.error(...) calls!

…emory.

We don't include apollo-boost in the bundlesize limits any more, but it
doesn't hurt to use these tools.

 - apollo-boost@0.3.0-beta.1
 - apollo-cache-inmemory@1.5.0-beta.1
 - apollo-cache@1.2.0-beta.1
 - apollo-client@2.5.0-beta.1
 - apollo-utilities@1.2.0-beta.1
 - graphql-anywhere@4.2.0-beta.1

 - apollo-boost@0.3.0-rc.0
 - apollo-cache-inmemory@1.5.0-rc.0
 - apollo-cache@1.2.0-rc.0
 - apollo-client@2.5.0-rc.0
 - graphql-anywhere@4.2.0-rc.0

 - apollo-boost@0.3.0-rc.1
 - apollo-cache-inmemory@1.5.0-rc.1
 - apollo-cache@1.2.0-rc.1
 - apollo-client@2.5.0-rc.1
 - apollo-utilities@1.2.0-rc.1
 - graphql-anywhere@4.2.0-rc.1

`ObservableQuery.getCurrentResult` can now return a result that
includes a `stale` property, which wasn't accounted for in the
returned `ApolloCurrentQueryResult` type.

The current code is returning a "Spread types may only be
created from object types" error when trying to understand
`{ ...prev, ...updater(prev) }`. This commit makes sure
typescript can tell the result is an object.

This reverts commit 2f197f8.

This change isn't necessary when using typescript >= 3.2, which
Apollo Client is configured to use. My global typescript was
stuck as 3.1, hence the unnecessary commit.

Recent jest config changes inadvertantly disabled all local
state tests.

Changes to make sure calling `npm run watch` in any of this
repo's child packages ensures the final bundles are built
after compilation has completed. For the full details on
why this is needed, see:

apollographql/react-apollo#2765

In an effort to simulate `defaults` behaviour from
`apollo-link-state`, we're leveraging cache results when
running local resolvers. The idea being that if a local resolver
isn't defined for a `@client` field, the local resolver
handling code can then fallback on using any matching cache
results, to resolve the field. While this works in theory,
it has introduced a few problems, like the one reported in #4474.

Since local resolvers adhere to Apollo Client's query fetch
policy, by defalut the cache is consulted first, when trying
to resolve a `@client` field. This means we shouldn't need to
attempt to resolve from the cache again, when processing local
resolvers, in most cases. There are a few situations where we
might want to do this, but the requirements are theoretical at
this point, and can be addressed in future changes if needed.

This commit removes the extra cache check, and adds
a test to verify that the behaviour reported in #4474 is fixed.

 - apollo-boost@0.3.0-rc.2
 - apollo-cache-inmemory@1.5.0-rc.2
 - apollo-cache@1.2.0-rc.2
 - apollo-client@2.5.0-rc.2
 - apollo-utilities@1.2.0-rc.2
 - graphql-anywhere@4.2.0-rc.2

The only reason we currently store/manage client typeDefs in the Apollo
Client codebase is so that they can be consumed by the Apollo DevTools in
development.

Because the DevTools do not have a public API, it's important for
developers to continue passing any client typeDefs to the ApolloClient
constructor, but we do not have to expose those typeDefs through any
convenient public API, and the LocalState class should not need to know
about them at all, much less perform any expensive normalization, since
all of that work can be done by the DevTools.

Instead, the typeDefs are now exposed as client.typeDefs, exactly as they
were originally passed to the ApolloClient constructor. Local resolvers
will no longer receive context.schemas, but that's no great loss because
the LocalState implementation is new in apollo-client@2.5.0. It would be
much harder to remove that functionality after shipping v2.5.0, which is
why it's important to do it now.

Thanks to this change, we're back to having zero imports of
graphql/language/printer in the Apollo Client codebase (though the printer
is still used by apollo-link).

@hwillson @justinanastos I realize there's been some churn in the way the
DevTools and the client communicate recently, but the good news is we can
iterate freely because it's a private API. Let me know if you have any
questions about this change!

* Enable local state only when client resolvers provided.

If an application was previously using apollo-link-state, updating to
apollo-client@2.5.0 could cause problems because @client fields are now
stripped by the integrated LocalState API, and thus will not be passed
into the link chain.

This commit should ease the transition by enabling the LocalState
functionality only if client resolvers were passed to the ApolloClient
constructor, or the LocalState#setResolvers method has been called.

If no client resolvers have been specified, @client fields will remain in
the query passed to the link chain, so apollo-link-state can still process
them, though a warning will be logged in development.

If you want to use @client directives to read from or write to the cache
without running resolver functions, you can pass an empty resolvers:{} map
to enable the LocalState functionality (including the stripping of @client
fields from queries).

* Refine private LocalState resolvers field type.

The setResolvers method normalizes Resolvers[] arrays into a combined
(non-array) Resolvers object.

 - apollo-boost@0.3.0-rc.3
 - apollo-client@2.5.0-rc.3