HTTP Cache API

[guybedford]

This implements the HTTP Cache API following the Rust implementation very closely, it is almost a verbatim translation of the Rust SDK semantics, apart from being adapted to the JS fetch API and using async send calls.

This feature uses the HTTP cache APIs only when they are both supported and also when adding the --enable-http-cache CLI argument to the js-compute runtime build command. The plan is to disable this flag for future versions and make it the default, but we want to be careful to ensure adequate testing and to avoid regressions.

Typing uses a variation of #1018 that uses real mutable Request and Response objects instead of relying on a new CandidateResponse object. The Response is effectively a CandidateResponse when it has a CacheEntry handle associated with it. A new error is then thrown when attempting to access the body of one of these response objects to support the CandidateResponse semantics. Effectively the CacheHandle slot being set handles the divergence here.

In the process, we also update new CacheControl('override', { ... opts ... }) to have the new direct override object syntax variation new CacheControl({ ...opts... }) as the override, and we also now support passing just the cache override init options to the cacheOverride fetch option, e.g. like fetch(url, { cacheOverride: { beforeSend () {...} } }).

The fetch implementation is upgraded to use send_async_v2 and the new implementation is very closely based to the Rust implementation which should replicate the former caching logic in its entirety making this mostly a backwards compatible change, pending further testing before unflagging.

Support for the fetch cache option is not implemented here although could now be partially implemented as per #1050, which is effectively unblocked by this landing.

• Resolves HTTP Cache API: JS SDK #991
• Resolves CacheOverride Simplifications #1052