Support federated service:check/push with local schema file

[JakeDawkins]

Right now, the only way to push/check a federated service is to use the --endpoint option and query the _service { sdl }. This is difficult to do in CI workflows because of other dependencies services may need in order to start up.

This PR adds the ability to specify a --localSchemaFile to use as a source of the sdl instead of querying a running service.

Constraints

• right now, the localSchemaFile must be a graphql file. The file used is interpreted as plain text and it passed directly to the check/push mutation, so anything file extensions other than graphql, gql, and graphqls will be errored.
  • We can't use a ts/js file, because we'd have to enforce a standard export name (or have it be the default export)
  • We can't use introspection json output, since theoretically at least the sdl with all federation directives wouldn't be able to be introspected properly.

Other

• Since sdl is now the only thing that's being queried from running services instead of the url and name, the federation-info providers aren't needed. The logic for loading the sdl can fit inside the existing schema providers.
• Renamed the introspection schema provider to endpoint since now there's more being fetched from an endpoint than the introspection query (_service { sdl })

usage

For the CLI, you can now use the --localSchemaFile flag to point to sdl

You can also add the file path in the config file to avoid using the flag

module.exports = {
  service: {
    name: 'JakeDawkins-1503',
    localSchemaFile: './src/schema.graphql'
  },
};

Along with client projects, the localSchemaFile also supports multiple values

In the apollo config file:

module.exports = {
  service: {
    name: 'JakeDawkins-1503',
    localSchemaFile: ['./src/schema.graphql', './src/schema2.graphql']
  },
};

as a CLI flag:

--localSchemaFile=schema.graphql,schema2.graphql

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

*Make sure changelog entries note which project(s) has been affected. See older entries for examples on what this looks like.