Allow a user-provided logger for Server, Gateway and AER

[abernix]

In general, Apollo Server and Apollo Gateway do very little outputting of messages (either informational or otherwise) to its console. Historically, both Server and Gateway have simply used various console methods (i.e. console.log) to output such messages without regard to "log levels" or other logger possibilities.

Using console methods does get the point across quite well in development, though it's less ideal for production environments which often demand a more structured approach to capturing their log messages across various stacks. For example, in containerized environments logs are often siphoned into various centralized log facilities and/or third party log providers (e.g. Datadog, Loggly, etc.).

Many users are already using existing loggers (like winston, log4js, bunyan and more) to report messages from their resolvers by exposing those logger implementations on their "context" using the context property to the ApolloServer constructor options. However, exposing a logger on the context doesn't allow Apollo Server to use it for its own important messaging and users should be able to opt into getting Apollo's own messages in the same log facilities.

Apollo Server will continue to be relatively quiet for now, but various sub-components (e.g. Gateway, Engine Reporting) are already outputting more and more important messages and warnings which deserve to get attention. In general, Apollo Gateway could certainly surface more logging (at various levels) and logger support would allow users to capture existing warnings and errors in one place.

Therefore, this introduces a relatively generic logger property to ApolloServer which will be made available on the GraphQLRequestContext that is already passed around in many places internally, received by various Gateway components (RemoteGraphQLDataSource), and also exposed to plugins, allowing well-considered plugins to utilize the same centralized log sink.

The ApolloGateway class will also support this logger, though for now, it will need to be passed in explicitly to both ApolloServer and ApolloGateway:

// For example purposes, I'm using `winston`, but you could
// create a logger with other packages linked in the footnotes.
const logger = require('winston').createLogger({
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: 'combined.log' })
  ]
});;

const gateway = new ApolloGateway({
  logger,
});

const server = new ApolloServer({
  gateway,
  logger,
});

// other important details have been left out!

This will also allow granular logging at various levels, including scoped or tagged logging, since the request pipeline could be used to create a sub-instance of a logger. For example, different components can accept their own logger property which, when set, will override any more-parent logger and allow logs to be sorted according to user preference. Apollo Engine will be the first-subcomponent to get this treatment. (engine will automatically inherit from ApolloServer).

Similarly, for logger implementations that support the notion of creating a sub-logger from an existing logger, the plugin life-cycle hooks can be used to create a user-specific logger in the requestDidStart life-cycle. This can be helpful in applying a user-id tag to all log messages which happened within the scope of a particular request. If the same logger should be made available to resolvers via exposure on the context, such plugin implementation on requestDidStartshould also augment the already-createdcontext` with the scoped-logger. Currently, there may be some typing restrictions that make this problematic, but in theory, it's certainly possible.

[trevor-scheer]

This looks great, @abernix. The new tests are always appreciated and make reviewing medium-larger PRs like this a breeze!