Support fetch cache option

[guybedford]

We could support the specified cache option for fetch with the following:

• 'default': This is our default so we exactly match the spec here
• 'no-store': This is the same as CacheOverride: pass so we can fully support this
• 'reload': Bypasses a cache check (so always goes to backend), then updates the cache - not possible, would require supporting insert without a successful transaction lookup
• 'no-cache': Always revalidates to the backend - same as above
• 'force-cache': Requires cache lookup ignoring staleness - not possible, but might make sense to support even if not properly implemented, since it’s kinda unobservable
• 'only-if-cached': As above

We should likely:

• Throw for 'reload' and 'no-cache'
• Support 'force-cache' and 'only-if-cached' with types / documentation warnings

[harmony7]

I have a concern regarding 'no-store' in conjunction with #1051 (HTTP Advanced Cache API)

If we define 'no-store' to be equivalent to CacheOverride: 'pass', then it means that fetch interaction will be bypassing the readthrough cache entirely. This means that neither the before-send nor after-send callbacks will be called. I think this would be surprising behavior from the viewpoint of a developer, because the label no-store sounds like it would do everything the same as default, except for lookup and storage.

If we do support no-store, then I would suggest that we still run the before-send, after-send, and body-transform callbacks for that request so that the developer won't be surprised.

[guybedford]

That makes sense.