The usage reporting plugin in `apollo-server-core` is not the first tool Apollo
built to report usage to Studio. Previous iterations such as `optics-agent` and
`engineproxy` reported a combination of detailed per-field single-operation
performance *traces* and summarized *stats* of operations to Apollo's
servers. When we built this TypeScript usage reporting plugin in 2018, for the
sakes of expediency we did something different: it only sent traces to Apollo's
servers. This meant that the performance of every single single user operation
was described in detail to Apollo's servers. Studio is not an exhaustive trace
warehouse: we have always *sampled* the traces received, making only some of
them available via Studio's Traces UI. The other traces were converted to stats
inside Studio's servers.

While this meant that the reporting agent was simpler than the previous
implementations (no need to be able to describe performance statistics), it also
meant that the protocol used to talk to Studio consumed a lot more bandwidth (as
well as CPU time for encoding traces).

This PR returns us to the world where Studio usage is reported as a combination
of stats and traces. It takes a slightly different approach than the previous
implementations: instead of reporting stats and traces in parallel, usage
reports contain both stats and traces. Each GraphQL operation is described
either as a trace or as stats, not both.

We expect this to significantly reduce the network and CPU requirements of
sending usage reports to Studio. It should not significantly affect the
experience of using Studio: we have always heavily sampled traces in Studio
before saving them to the trace warehouse, and the default heuristic for which
operations to send as traces works similarly to the heuristic used in Studio's
servers.

This PR introduces an option `experimental_sendOperationAsTrace` to allow you to
control whether a given operation is sent as trace or stats. This is truly an
experimental option that may change at any time. For example, you should not
rely on the fact that this will be called on all operations after the operation
is done with a full, or on its signature, or even that it exists. It is likely
that future improvements to the usage reporting plugin will change how
operations are observed so that we don't have to collect a full trace before
deciding how to represent the operation.

Some other notes:

- Upgrade our fork `@apollo/protobufjs` with a few improvements:
  - New `js_use_toArray` option which lets you encode repeated fields from
    objects that aren't stored in memory as arrays but expose `toArray`
    methods. We use this so that we can build up `DurationHistogram`s and
    map-like objects in a non-array fashion and only convert to array at
    encoding time.
  - New `js_preEncoded` option which allows you to encode messages in repeated
    fields as buffers (Uint8Arrays). This helps amortize encoding cost of a
    large message over time instead of freezing the event loop to encode the
    whole message at once. This replaces an old hack we used for one field with
    something built in to the protobuf compiler (including correct TypeScript
    typings).
  - New `--no-from-object` flag which we use to reduce the size of generated
    code (as we don't use the fromObject protobuf.js API).
- In order to help us validate that the trace->stats code in this PR matches
  similar code in Studio's servers, the flag
  `internal_includeTracesContributingToStats` sends the traces that contribute
  to stats in a special field. This is something we only use as part of our own
  validation in our servers; for your graphs it will have no effect other than
  increasing message size.
- Viewing traces in Studio is only available on paid plans. The usage-reporting
  endpoint now tells the plugin whether traces are supported on your graph's
  plan; if not supported, the plugin will switch to sending all operations as
  stats (regardless of the value of `experimental_sendOperationAsTrace`) after
  the first report.
- We try to estimate the message size compared to maxUncompressedReportSize via
  a rough estimate about how big the leaf nodes of the stats messages will be
  rather than carefully counting how much space is used by each number and
  histogram. We do take the lengths of all strings into account.
- By mistake, this plugin never sent the cache policy on traces, meaning that
  visualizing cache-specific stats in Studio did not work. This is now fixed.

This project was begun by @jsegaran and completed by @glasser.

 - apollo-cache-control@0.13.0-alpha.0
 - apollo-datasource-rest@0.13.0-alpha.0
 - apollo-datasource@0.9.0-alpha.0
 - apollo-reporting-protobuf@0.7.0-alpha.0
 - apollo-server-azure-functions@2.24.0-alpha.0
 - apollo-server-cache-memcached@0.8.0-alpha.0
 - apollo-server-cache-redis@1.5.0-alpha.0
 - apollo-server-caching@0.7.0-alpha.0
 - apollo-server-cloud-functions@2.24.0-alpha.0
 - apollo-server-cloudflare@2.24.0-alpha.0
 - apollo-server-core@2.24.0-alpha.0
 - apollo-server-env@3.1.0-alpha.0
 - apollo-server-express@2.24.0-alpha.0
 - apollo-server-fastify@2.24.0-alpha.0
 - apollo-server-hapi@2.24.0-alpha.0
 - apollo-server-integration-testsuite@2.24.0-alpha.0
 - apollo-server-koa@2.24.0-alpha.0
 - apollo-server-lambda@2.24.0-alpha.0
 - apollo-server-micro@2.24.0-alpha.0
 - apollo-server-plugin-base@0.12.0-alpha.0
 - apollo-server-plugin-operation-registry@0.10.0-alpha.0
 - apollo-server-plugin-response-cache@0.8.0-alpha.0
 - apollo-server-testing@2.24.0-alpha.0
 - apollo-server-types@0.8.0-alpha.0
 - apollo-server@2.24.0-alpha.0
 - apollo-tracing@0.14.0-alpha.0
 - graphql-extensions@0.14.0-alpha.0

See apollographql/protobuf.js#7

A future version could fully remove Long support from our fork but we
aren't quite there yet.

 - apollo-cache-control@0.13.0-alpha.1
 - apollo-datasource-rest@0.13.0-alpha.1
 - apollo-reporting-protobuf@0.7.0-alpha.1
 - apollo-server-azure-functions@2.24.0-alpha.1
 - apollo-server-cloud-functions@2.24.0-alpha.1
 - apollo-server-cloudflare@2.24.0-alpha.1
 - apollo-server-core@2.24.0-alpha.1
 - apollo-server-express@2.24.0-alpha.1
 - apollo-server-fastify@2.24.0-alpha.1
 - apollo-server-hapi@2.24.0-alpha.1
 - apollo-server-integration-testsuite@2.24.0-alpha.1
 - apollo-server-koa@2.24.0-alpha.1
 - apollo-server-lambda@2.24.0-alpha.1
 - apollo-server-micro@2.24.0-alpha.1
 - apollo-server-plugin-base@0.12.0-alpha.1
 - apollo-server-plugin-operation-registry@0.10.0-alpha.1
 - apollo-server-plugin-response-cache@0.8.0-alpha.1
 - apollo-server-testing@2.24.0-alpha.1
 - apollo-server-types@0.8.0-alpha.1
 - apollo-server@2.24.0-alpha.1
 - apollo-tracing@0.14.0-alpha.1
 - graphql-extensions@0.14.0-alpha.1

* chore(deps): update dependency node-fetch to v2.6.1

* tests: Use `toString()` method to test Buffer contents

As of `node-fetch@2.4.0`, its internal representation of `body` is now
normalized to a `Buffer` during `Request` construction, and will always be
returned as a `Buffer`, rather than having the `body` being either a String
_or_ a Buffer.  This defeated the way we were testing the `body` but
shouldn't affect the actual `Response`'s `body`.

Ref: node-fetch/node-fetch@7d3293200a91a

Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Jesse Rosenberger <git@jro.cc>

…5144)

Co-authored-by: Renovate Bot <bot@renovateapp.com>

 - apollo-cache-control@0.13.0-alpha.2
 - apollo-datasource-rest@0.13.0-alpha.2
 - apollo-reporting-protobuf@0.7.0-alpha.2
 - apollo-server-azure-functions@2.24.0-alpha.2
 - apollo-server-cloud-functions@2.24.0-alpha.2
 - apollo-server-cloudflare@2.24.0-alpha.2
 - apollo-server-core@2.24.0-alpha.2
 - apollo-server-express@2.24.0-alpha.2
 - apollo-server-fastify@2.24.0-alpha.2
 - apollo-server-hapi@2.24.0-alpha.2
 - apollo-server-integration-testsuite@2.24.0-alpha.2
 - apollo-server-koa@2.24.0-alpha.2
 - apollo-server-lambda@2.24.0-alpha.2
 - apollo-server-micro@2.24.0-alpha.2
 - apollo-server-plugin-base@0.12.0-alpha.2
 - apollo-server-plugin-operation-registry@0.10.0-alpha.2
 - apollo-server-plugin-response-cache@0.8.0-alpha.2
 - apollo-server-testing@2.24.0-alpha.2
 - apollo-server-types@0.8.0-alpha.2
 - apollo-server@2.24.0-alpha.2
 - apollo-tracing@0.14.0-alpha.2
 - graphql-extensions@0.14.0-alpha.2

 - apollo-cache-control@0.13.0
 - apollo-datasource-rest@0.13.0
 - apollo-datasource@0.9.0
 - apollo-reporting-protobuf@0.7.0
 - apollo-server-azure-functions@2.24.0
 - apollo-server-cache-memcached@0.8.0
 - apollo-server-cache-redis@1.5.0
 - apollo-server-caching@0.7.0
 - apollo-server-cloud-functions@2.24.0
 - apollo-server-cloudflare@2.24.0
 - apollo-server-core@2.24.0
 - apollo-server-env@3.1.0
 - apollo-server-express@2.24.0
 - apollo-server-fastify@2.24.0
 - apollo-server-hapi@2.24.0
 - apollo-server-integration-testsuite@2.24.0
 - apollo-server-koa@2.24.0
 - apollo-server-lambda@2.24.0
 - apollo-server-micro@2.24.0
 - apollo-server-plugin-base@0.12.0
 - apollo-server-plugin-operation-registry@0.10.0
 - apollo-server-plugin-response-cache@0.8.0
 - apollo-server-testing@2.24.0
 - apollo-server-types@0.8.0
 - apollo-server@2.24.0
 - apollo-tracing@0.14.0
 - graphql-extensions@0.14.0