…al API."

This reverts commit 6d6c9ff.

This reverts commit 96af44e.

This reverts commit 408198e.

This reverts commit 4175f1b.

* Allow an optional function to resolve the rootValue

Passes the parsed DocumentNode AST to determine the root value,
useful when providing a different rootValue for query vs mutation

* Add API docs for rootValue

* Provide ability to specify client info in traces

Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.

* Use extensions and context in createClientInfo

* Remove support for clientAddress

The frontend will not support it in the near future

* create -> generate and make default generator

createClientInfo -> generateClientInfo

* Clarify default values

The `generateClientInfo` API, used to set client identification attributes
within traces, is an experimental API and is subject to removal or change in
a future (major) Apollo Server release.

Ref: #1631

…tests.

The linting will happen in CircleCI.  Additionally, we already have
post-commit hooks so doing linting on every test run seems to just be
generally slowing down development since any linting problems are
automatically fixed when I do a commit.

The ability to pass in functions or promises shouldn't affect the type variable.

…pto`.

This silences the deprecation messages which have been showing up in recent
local development on the new request pipeline work.  e.g.:

> ```
> [DEP0010] DeprecationWarning: crypto.createCredentials is deprecated.
>   Use tls.createSecureContext instead.
> [DEP0011] DeprecationWarning:
>   crypto.Credentials is deprecated. Use tls.SecureContext instead.
> ```

…ControlExtension

The actual resolving of the context happens in ApolloServer#graphQLServerOptions, but errors thrown while doing that are currently converted to a throwing function.

… into HEAD

…pto`.

This silences the deprecation messages which have been showing up in recent
local development on the new request pipeline work.  e.g.:

> ```
> [DEP0010] DeprecationWarning: crypto.createCredentials is deprecated.
>   Use tls.createSecureContext instead.
> [DEP0011] DeprecationWarning:
>   crypto.Credentials is deprecated. Use tls.SecureContext instead.
> ```

While cacheControl can take a boolean when passing it in  to ApolloServer as part of a Config, these will be converted to default options before passing them on as options.

…}?.json`.

…est-pipeline

…nto abernix/re-new-request-pipeline

We compile `requestPipelineAPI.ts` as a separate TypeScript project to avoid circular dependency issues from the `apollo-server-plugin-base` package depending on the types in `apollo-server-core`.

Since activating the EngineReportingAgent is now dependent on being able to extract an engineServiceId from the API key, tests need to specify one that follows the expected structure.

…onal

…text

…thods

…est-pipeline

* Pass the context along to all the extension methods

Addresses #1343

With this change you should now be able to implement an extension like so:

```javascript
class MyErrorTrackingExtension extends GraphQLExtension {
    willSendResponse(o) {
        const { context, graphqlResponse } = o

        context.trackErrors(graphqlResponse.errors)

        return o
    }
}
```

Edit by @evans :
fixes #1343
fixes #614 as the request object can be taken from context or from requestDidStart
fixes #631 ""

* Remove context from extra extension functions

The context shouldn't be necessary for format, parse, validation, and
execute. Format generally outputs the state of the extension. Parse and
validate don't depend on the context. Execution includes the context
argument as contextValue

* Move change entry under vNext

…eline.

Prior to embarking on the request pipeline work, and to facilitate
development on the new request pipeline, @martijnwalraven and myself
intentionally reverted some commits that had been recently introduced but
conflicted with the request pipeline branch that was already in-flight.

Rather than dealing with an incredibly difficult merge conflict, it was
easier to revert them an re-apply them later.

Original commits, reversions, and reintroductions:

* 6d6c9ff, 03a894d, b90ccc2
* 96af44e, 68c82e6, 81c4642
* 408198e, 2b470e1, 84bc834
* 4175f1b, 38e7b6a, 261994c

As is demonstrated by this short follow-up commit, this was all that was
necessary to make it work in the new model - once that model was finished.

While we're certain that the new request pipeline and its plugin model will
actually better support some of the behavior that required these initial
commits in the name of not introducing breaking changes, we feel it's
necessary to maintain their support.

I will point out, if you are at all affected by the above commits, we may
consider deprecating portions of those APIs in the not too distant future,
but we hope that the new model will help support those needs even better.