Apollo Server 2.0 - Add public getters for SubscriptionServer and HTTPServer

[lukebarton]

To enable people to instrument and log requests served by Apollo Server, we should expose the subscription server and http server to them.

This would allow people to make use of

const apollo = new ApolloServer({...});
apollo.listen({...}).then(() => {
  apollo.getSubscriptionServer().server.on('<Socket Server Event>', cb);
  apollo.getHttpServer().on('<HTTP Server Event>', cb);
});

Motivation:
The logging isn't very good at the moment. It's pretty terrible. If I want to understand my logs then I need to know the req which the res originated from. Currently the logging simply emits anonymous events with very little meta and I have no way to tie log entries to preceding log entries. By exposing the servers, I can at least hook into the server lifecycles and then, for example, uniquely identify each request or connection with a generated uuid to achieve some context-aware logging and add some instrumentation (response times, number of open socket connections, etc).

Along the same vein, it might be useful for the Apollo Server to use an event emitter to advertise it's own GraphQL lifecycle events (with useful callback arguments) and allow people to hook into them. The tracing and logging could then simply listen to these events, decoupled from the server itself. It'd be trivial for people to use the emitted events for their own purposes too (e.g. custom logging, tracing or other instrumentation).

Ideally I'd like to be able to tie a Query to a specific request or socket connection (and socket message).

If a maintainer will accept the premise of this PR then I will complete the CLA and the TODOs - alternatively, a maintainer can implement this in their own commits/PR

TODO:

• Update CHANGELOG.md with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

[apollo-cla]

@lukebarton: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[evans]

@lukebarton Thank you for opening the PR! I hear you about the limitation of logging. Exposing graphql-extensions as a public api is a start to exposing the lifecycle methods of a server #1105. Are there more that you would like to see? https://github.com/apollographql/graphql-extensions/pull/12 is the extensions.

Since ApolloServer is going to be used across a bunch of different environments, such as cloudflare and lambda, which don't have http listeners or websockets, I'm inclined towards exposing more lifecycle methods rather than the underlying primitives. Is there functionality or information that requires access to the servers that lifecycle methods wouldn't provide?

[evans]

@lukebarton This is still a possibility for the apollo-server package. Do you think that's worthwhile?

For the other integrations, the user is in charge of launch their own http listener after applying the middleware from Apollo Server

[evans]

Thank you for the original idea! I'm going to close this now, since we changed to a design that allows control over the listener.