Perf and other improvements for querying extensions

Created by: sqs

Overall, this makes the graphql?Extensions call ~820ms faster (which helps every page load) and lengthens the time that a Sourcegraph instance caches the Sourcegraph.com extension registry data.

Partially (but not fully) fixes #10554 (closed). Further perf improvements will require GraphQL schema changes, which are more complex.

See individual commits:

• better Cache-Control and fixed Vary header for extension registry API responses

  The HTTP request from the extension registry listing all the extensions is now cached for 120s (was 30s). This HTTP request needs to fetch ~800kb (compressed) of JSON data from Sourcegraph.com, and caching it for longer will have minimal negative consequences (because extensions don't change very often) and will marginally reduce how often this data needs to be re-fetched and a user needs to wait for it.

  The extension registry's Vary header was being set incorrectly. The Vary header should list the names of request headers that help determine if a cached response is valid. But we were including response headers, which didn't cause any issues (because the requests didn't even include this header).

• trace list API call to extension registry

  There is now tracing for the registry API client's HTTP requests to get a list of all extensions from the registry (usually Sourcegraph.com). This is a slow HTTP request and it fetches a lot of data (~800kb uncompressed), so it's helpful to see it in traces.

• close HTTP response body in extension registry fetch

  The response body was most likely buffered by some transport wrapper, so this probably didn't actually result in a leak, but of course it's good practice to always close the response body.

• fast path for IsWorkInProgressExtension (speeds up graphql?Extensions)

  The GraphQL RegistryExtensionConnectionResolver sorts extensions in several ways, most of which are fast. However, sorting by WIP (i.e., showing WIP extensions last) is very slow (~900ms on my machine on the list of extensions returned by Sourcegraph.com), because it needs to jsonc-parse each extension manifest for each sort comparison.

  This fast path reduces the total time for the sort from ~900ms to ~74ms (which means the graphql?Extensions query, which runs on each page load, takes that much less time). Further improvements can be gained by caching this so that it just needs to be run n times (to sort n items) instead of O(n*log(n)) times.

• remove backcompat for extension titles starting with "WIP:"

  Work-in-progress extensions are indicated by having "wip": true in their package.json manifest. Previously, in 2018, we considered extensions WIP if their title started with WIP: or [WIP] . When we introduced the simpler wip field on package.json, we left in backcompat for extensions that indicated WIP in their title.

  It is safe to remove this backcompat because the wip field on package.json has been present for ~3 years. (Also, even the title field was removed for extensions back in 2018 (in favor of just name, like npm).)