This re-introduces the TypeScript query planner code as of apollographql/apollo-server@60d9742, which is one of the parents of the commit that deleted that code from the `apollo-server` repository: apollographql/apollo-server@149f78e.

I wanted to start out with this to then re-apply the changes I've made in an experimental repository in a more tractable manner.

On top of that, this commit adds a `composedSchema` directory, which contains code that is used to build a schema with Federation metadata from CSDL (this will be replaced with code that takes a core schema file with join directives as input). That was needed to get things wired up with the current gateway code.

 We temporarily export the same API we used for the wasm query planner from `@apollo/query-planner`, but implemented as a facade on top of the TypeScript one. This is ugly and inefficient (we shouldn't be parsing the query again), but the goal is to get things working first without making changes to the gateway code.

The original code used `getFederationMetadata` from `@apollo/federation`, which is a private utility function that works based on the internal metadata added to the `GraphQLSchema` that's being built up during composition.

Since the query planner has its own `buildComposedSchema` now, which uses CSDL as input and builds its own `GraphQLSchema`, we need to switch to its utility functions instead.

(We expose separate `getFederationMetadataForType` and `getFederationMetadataForField` functions because there is no need to support both with the same function and that avoids runtime checks.)

… package

The corresponding test in `@apollo/gateway` (`single-service.test.ts`) uses a simple value type, not a union. To make sure we come back to this, I've left the union type in there and introduced an additional failing test.

…instead of `null`

This replicates the behavior of the current Rust query planner, because I wanted to get the tests passing before making further changes. But the type explosion fix this depends on is fundamentally flawed and needs to be replaced.

This code has more problems and should be replaced by proper recursive selection set merging, but removing the unnecessary distinction between aliased fields and non-aliased fields at least fixes the test.

The disabled test covers code that was added to the Rust query planner to fix #177, but that logic is problematic and we should have a more principled discussion about propagation of executable directives first.

The order of the generated fragments seems to differ between the Rust query planner and the TypeScript one. Since this shouldn't change the semantics of the query, updating the snapshots to make the tests pass.

The generated core schema was invalid because the `@join__type` directive definition should be repeatable and have `key` as its argument (instead of `requires` and `provides`). We would also generate a `@join__field` directive without a graph name in case `serviceName` was undefined, which would lead to a syntax error when parsing.

This commit also renames `@http` to `@join__endpoint` and includes a directive definition for it (which was missing before).

The goal here is to get the tests passing first, while making as few changes to the gateway as possible. That means the way the gateway generates composed schemas and service lists performs redundant work and should be cleaned up later.

We should rethink the way we handle value types in composition. Currently, a type is only seen as a value type if it is defined in more than one service. Those aren't the right semantics because a type that is only defined in one service can still be a value type if it doesn't have a `@key`. That wasn't an issue before, but with the join spec that means we end up generating `@join__field` directives on fields of what should be value types.

A particularly thorny issue is the use of `@provides` on fields of value types, which if allowed, should only apply to the subgraph that includes it. We don't currently keep track of `@requires`/`@provides` per subgraph however, plus `join__field` is defined as non repeatable, so there is no easy way to generate the correct metadata.

The generated core schema was invalid because the `@join__type` directive definition should be repeatable and have `key` as its argument (instead of `requires` and `provides`). We would also generate a `@join__field` directive without a graph name in case `serviceName` was undefined, which would lead to a syntax error when parsing.

This commit also renames `@http` to `@join__endpoint` and includes a directive definition for it (which was missing before).

To make the schema returned from `buildComposedSchema` reflect the API schema, we filter out core and join elements. The approach is naive and doesn't follow the Core Schema spec, but it should work for the core SDL currently printed from `printComposedSchema` in `@apollo/federation`.

…ut `graph`

Allowing `@join__field` without `graph` gives us the same metadata previously computed from CSDL input, and should keep the query planner behavior the same as before.

In the future, we should probably change composition to keep track of `@provides` on a per subgraph basis, and reflect that in the core schema output by making `@join__field` repeatable and `graph` non-nullable.

We should change the way we detect value types. If a type is defined in only one service, we currently don't consider it a value type even if it doesn't specify any keys.

That resulted in us printing `@join__field`, with the name of the single service that defined the type, even though we didn't add a corresponding `join__type` to the parent type (because that relies on there being keys defined). That is invalid according to the join spec, and also broke the current workaround for avoiding type explosion on value types (which we should replace, but are leaving in for now to first replicate the existing behavior).

This was always the recommended style, but now that `GraphQLNonNull` and `GraphQLList` have been converted to proper classes in graphql/graphql-js#2906, calling them as functions no longer works.

This replicates the behavior added to the Rust query planner in #178.

Unfortunately, the logic in there is seriously flawed, and may lead to unexpected results. The assumption seems to be that fields with the same parent type are always nested in the same inline fragment. That is not necessarily true however, and because we take the directives from the scope of the first field with a particular parent type, those directives will be applied to all other fields that have the same parent type even if the directives aren't meant to apply to them because they were nested in a different inline fragment. (That also means that if the scope of the first field doesn't have directives, directives that would have applied to other fields will be lost.)

(Note that this also applies to `@skip` and `@include`, which could lead to invalid query plans that fail at runtime because expected fields are missing from a subgraph response.)

We need to make sure the string values we print are valid GraphQL string literals. If a value includes a quote or backslash for example, these need to be escaped to avoid parser errors.

We're relying on `JSON.stringify` for this, which the `graphql-js` printer also uses when printing out a `StringValue`: https://github.com/graphql/graphql-js/blob/d4bcde8d3e7a7cb8462044ff21122a3996af8655/src/language/printer.js#L109-L112

Also updates snapshots of command's output.

This code remains untested since this path is unsupported by
composition currently. There is a related issue polaris-planning#62
which should be referenced when building out the rest of this
functionality.

Remove all notions of CSDL in code. Replaced with "Supergraph SDL" or
its appropriately camelCased counterpart.