Version Packages (#7174)

This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.


# Releases
## @apollo/[email protected]

### Minor Changes

- [#7171](#7171)
[`37b3b7fb5`](37b3b7f)
Thanks [@glasser](https://github.com/glasser)! - If a POST body contains
a non-string `operationName` or a non-object `variables` or
`extensions`, fail with status code 400 instead of ignoring the field.

In addition to being a reasonable idea, this provides more compliance
with the "GraphQL over HTTP" spec.

This is a backwards incompatible change, but we are still early in the
Apollo Server 4 adoption cycle and this is in line with the change
already made in Apollo Server 4 to reject requests providing `variables`
or `extensions` as strings. If this causes major problems for users who
have already upgraded to Apollo Server 4 in production, we can consider
reverting or partially reverting this change.

### Patch Changes

- [#7170](#7170)
[`4ce738193`](4ce7381)
Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Update
@apollo/utils packages to v2 (dropping node 12 support)

- [#7179](#7179)
[`c8129c23f`](c8129c2)
Thanks [@renovate](https://github.com/apps/renovate)! - Fix a few tests
to support (but not require) TypeScript 4.9.

- [#7171](#7171)
[`37b3b7fb5`](37b3b7f)
Thanks [@glasser](https://github.com/glasser)! - The integration test
suite now incorporates the `graphql-http` package's audit suite for the
"GraphQL over HTTP" specification.

- [#7183](#7183)
[`46af8255c`](46af825)
Thanks [@glasser](https://github.com/glasser)! - Apollo Server tries to
detect if execution errors are variable coercion errors in order to give
them a `code` extension of `BAD_USER_INPUT` rather than
`INTERNAL_SERVER_ERROR`. Previously this would unconditionally set the
`code`; now, it only sets the `code` if no `code` is already set, so
that (for example) custom scalar `parseValue` methods can throw errors
with specific `code`s. (Note that a separate graphql-js bug can lead to
these extensions being lost; see
<graphql/graphql-js#3785> for details.)

- Updated dependencies
\[[`4ce738193`](4ce7381),
[`37b3b7fb5`](37b3b7f),
[`b1548c1d6`](b1548c1),
[`7ff96f533`](7ff96f5),
[`46af8255c`](46af825)]:
    -   @apollo/[email protected]

## @apollo/[email protected]

### Minor Changes

- [#7171](#7171)
[`37b3b7fb5`](37b3b7f)
Thanks [@glasser](https://github.com/glasser)! - If a POST body contains
a non-string `operationName` or a non-object `variables` or
`extensions`, fail with status code 400 instead of ignoring the field.

In addition to being a reasonable idea, this provides more compliance
with the "GraphQL over HTTP" spec.

This is a backwards incompatible change, but we are still early in the
Apollo Server 4 adoption cycle and this is in line with the change
already made in Apollo Server 4 to reject requests providing `variables`
or `extensions` as strings. If this causes major problems for users who
have already upgraded to Apollo Server 4 in production, we can consider
reverting or partially reverting this change.

- [#7184](#7184)
[`b1548c1d6`](b1548c1)
Thanks [@glasser](https://github.com/glasser)! - Don't automatically
install the usage reporting plugin in servers that appear to be hosting
a federated subgraph (based on the existence of a field `_Service.sdl:
String`). This is generally a misconfiguration. If an API key and graph
ref are provided to the subgraph, log a warning and do not enable the
usage reporting plugin. If the usage reporting plugin is explicitly
installed in a subgraph, log a warning but keep it enabled.

### Patch Changes

- [#7170](#7170)
[`4ce738193`](4ce7381)
Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Update
@apollo/utils packages to v2 (dropping node 12 support)

- [#7172](#7172)
[`7ff96f533`](7ff96f5)
Thanks [@trevor-scheer](https://github.com/trevor-scheer)! -
startStandaloneServer: Restore body-parser request limit to 50mb (as it
was in the `apollo-server` package in Apollo Server 3)

- [#7183](#7183)
[`46af8255c`](46af825)
Thanks [@glasser](https://github.com/glasser)! - Apollo Server tries to
detect if execution errors are variable coercion errors in order to give
them a `code` extension of `BAD_USER_INPUT` rather than
`INTERNAL_SERVER_ERROR`. Previously this would unconditionally set the
`code`; now, it only sets the `code` if no `code` is already set, so
that (for example) custom scalar `parseValue` methods can throw errors
with specific `code`s. (Note that a separate graphql-js bug can lead to
these extensions being lost; see
<graphql/graphql-js#3785> for details.)

- Updated dependencies
\[[`4ce738193`](4ce7381),
[`45856e1dd`](45856e1)]:
    -   @apollo/[email protected]

## @apollo/[email protected]

### Patch Changes

- [#7170](#7170)
[`4ce738193`](4ce7381)
Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Update
@apollo/utils packages to v2 (dropping node 12 support)

- [#7173](#7173)
[`45856e1dd`](45856e1)
Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Remove
unnecessary engines constraint on types-only package

## @apollo/[email protected]

### Patch Changes

- [#7170](#7170)
[`4ce738193`](4ce7381)
Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Update
@apollo/utils packages to v2 (dropping node 12 support)

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

Author: github-actions[bot]