…ns".

Similar to 6009d8a (#3991) and 68cbc93 (#3997), which migrated the
tracing and cache-control extensions to the (newer) request pipeline plugin
API, this commit introduces:

 - Internally, a `plugin` named export which is utilized by the `agent`'s
   `newExtension` method to provide a plugin which is instrumented to
   transmit metrics to Apollo Graph Manager.  This plugin is meant to
   replicate the behavior of the `EngineReportingExtension` class which,
   as of this commit, still lives besides it.
 - Externally, a `federatedPlugin` exported on the main module of the
   `apollo-engine-reporting` package.  This plugin is meant to replicate the
   behavior of the `EngineFederatedTracingExtension` class (also exported on
   the main module) which, again as of this commit, still lives besides it!

Again, the delta of the commits seemed more confusing by allowing a natural
`diff` to be made of it, I've left the extensions in place so they can be
compared - presumably side-by-side in an editor - on the same commit.  An
(immediate) subsequent commit will remove the extension.

This fixes the failing tests which correctly surfaced on the last commit.

Previously, prior to the new plugin API, the Apollo Engine Reporting
mechanism was implemented using `graphql-extensions`, the API for which
didn't invoke `requestDidStart` until _after_ APQ had been negotiated.

The new plugin API starts its `requestDidStart` _before_ APQ validation and
various other assertions which weren't included in the `requestDidStart`
life-cycle, even if they perhaps should be in terms of error reporting.

The new plugin API is able to properly capture such errors within its
`didEncounterErrors` lifecycle hook (thanks to
#3614, which
intentionally captures these failures so plugin authors can accurately react
to them), however, for behavioral consistency reasons, we will still
special-case those errors and maintain the legacy behavior to avoid a
breaking change.  We can reconsider this in a future version of Apollo
Engine Reporting (AS3, perhaps!).

Ref: #3614
Ref: #3627
Ref: #3638

The plugin implementation brought in de7ba72 supersedes the need for
this implementation!

Ref: #3998

This was inadvertently removed in the re-factor.

Ref: https://github.com/apollographql/apollo-server/pull/3998/files#r414901517

...and destructuring.

This eliminates the need to guard for the presence of `metrics` on the
`requestContext` within plugins who are calling `requestDidStart`.

Ref: #3998 (comment)

As noted in review within [[1]], there wasn't really a compelling reason for
this to be kept separately from the other tree-building bits which existed
within `ensurePreflight`.

[1]: #3998 (comment)

…tring`.

The use of `document` and `source` is the standard within the plugin API and
the request pipeline, so these names should be more natural going forward.

This wouldn't have been possible without a breaking change, but we're
already doing that.

Per @glasser's a8ab841e#r38802002

…abernix/migrate-engine-reporting-exts-to-plugin-api

…ponse.

Ref: https://github.com/apollographql/apollo-server/pull/3998/files#r414902801

Ref: https://github.com/apollographql/apollo-server/pull/3998/files#r409729299

…abernix/migrate-engine-reporting-exts-to-plugin-api

…to abernix/migrate-engine-reporting-exts-to-plugin-api

…to abernix/migrate-engine-reporting-exts-to-plugin-api

I may re-visit this consideration.

…rce`.

Leverages new life-cycle `didResolveSource` which was introduced by
[[PR #4076]] and inspired by this [[comment]].

This is much nicer!

[PR #4076]: #4076
[Comment]: https://github.com/apollographql/apollo-server/pull/3998/files#r414911049

@glasser, are you able to confirm this belief and that it should be okay?

…w traced."

This reverts commit 6d4777d.

Previously, I introduced a work-around for this in 78a4cb7,
though that is no longer necessary with the introduction of
`didResolveSource` in #4076

I'm thrilled to remove this!

Ref: #3998 (comment)

…to abernix/migrate-engine-reporting-exts-to-plugin-api

… failure.

Addresses feedback in below referenced [[Comment]].

If operation resolution (parsing and validating the document followed by
selecting the correct operation) resulted in the population of the
`operationName`, we'll use that. (For anonymous operations,
`requestContext.operationName` is null, which we represent here as the empty
string.)

If the user explicitly specified an `operationName` in their request but
operation resolution failed (due to parse or validation errors or because
there is no operation with that name in the document), we still put _that_
user-supplied `operationName` in the trace. This allows the error to be
better understood in Graph Manager. (We are considering changing the
behavior of `operationName` in these three error cases; see [[#3465]] below for
details.)

[Comment]: #3998 (comment)
[#3465]: #3465

…to abernix/migrate-engine-reporting-exts-to-plugin-api

Implements pattern gained by a926b7e in #3988.

Ref: #3998

Ref: b0948a8

…abernix/migrate-engine-reporting-exts-to-plugin-api

…xts-to-plugin-api

…rate-engine-reporting-exts-to-plugin-api