plugins: Declare types rather than use in-line types for life-c… (apo…

…llographql/apollo-server#3902)

* plugins: Declare types rather than use in-line types for life-cycle hooks.

This makes it easier to reason about the types and to keep things DRY, in
addition to preserving a more real stacking of types as the stages of server
life-cycles progress.  E.g., `validationDidStart` will have a super-set of
`Required` properties which were present in the `parsingDidStart` phase.
Now, rather than actually repeating them verbosely, they will be intersected.

These new explicit types will live in `apollo-server-types` where they can
also be relied upon by `@apollo/gateway` and other packages, but they'll
also be exported directly from the `apollo-server-plugin-base` package.

Reason being: The overall concept of `apollo-server-types` and this
`apollo-server-plugin-base` package is that they should NOT depend directly
on "core", in order to avoid close coupling of plugin support and specific
server versions.  In other words, someone should be able to install a
version of a plugin that depends on `apollo-server-plugin-base` in their
application which uses a semver compatible plugin API but NOT the same
semver range of `apollo-server-core`, though they are currently similar.

They are duplicated concepts right now where one package is intended to be
for public plugin exposure (`-plugin-base`), while the other (`-types`) is
meant to be used internally.  In the future, `apollo-server-types` and
`apollo-server-plugin-base` will probably roll into the same "types"
package, but that is not today!

* plugins: Same as `source`, `queryHash` is required at `parsingDidStart`.

They are defined at the same time, as noted in the referenced link.

Ref: https://github.com/apollographql/apollo-server/blob/eadcc6b4/packages/apollo-server-core/src/requestPipeline.ts#L196-L197

* Remove unnecessary casting.

Per: https://github.com/apollographql/apollo-server/pull/3902/files#r395767682
Thanks to: d1b7a82
Apollo-Orig-Commit-AS: apollographql/apollo-server@7e09cf2

gateway-js/src/index.ts

@@ -6,9 +6,8 @@ import {
 } from 'apollo-server-core';
 import {
   GraphQLExecutionResult,
-  GraphQLRequestContext,
   Logger,
-  WithRequired,
+  GraphQLRequestContextExecutionDidStart,
 } from 'apollo-server-types';
 import { InMemoryLRUCache } from 'apollo-server-caching';
 import {
@@ -148,11 +147,6 @@ export type Experimental_UpdateServiceDefinitions = (
 
 type Await<T> = T extends Promise<infer U> ? U : T;
 
-type RequestContext<TContext> = WithRequired<
-  GraphQLRequestContext<TContext>,
-  'document' | 'queryHash'
->;
-
 // Local state to track whether particular UX-improving warning messages have
 // already been emitted.  This is particularly useful to prevent recurring
 // warnings of the same type in, e.g. repeating timers, which don't provide
@@ -569,7 +563,7 @@ export class ApolloGateway implements GraphQLService {
   // are unlikely to show up as GraphQLErrors. Do we need to use
   // formatApolloErrors or something?
   public executor = async <TContext>(
-    requestContext: RequestContext<TContext>,
+    requestContext: GraphQLRequestContextExecutionDidStart<TContext>,
   ): Promise<GraphQLExecutionResult> => {
     const { request, document, queryHash } = requestContext;
     const queryPlanStoreKey = queryHash + (request.operationName || '');
@@ -682,7 +676,7 @@ export class ApolloGateway implements GraphQLService {
   };
 
   protected validateIncomingRequest<TContext>(
-    requestContext: RequestContext<TContext>,
+    requestContext: GraphQLRequestContextExecutionDidStart<TContext>,
     operationContext: OperationContext,
   ) {
     // casting out of `readonly`