[ServiceWorker] Define some way for foreign fetch to decide on opaqueness of responses (#841)

A service worker with a foreign fetch handler needs some kind of API to decide if responses it returns should be opaque responses or not when received by whoever initiated the fetch (as currently specified all responses will be opaque, which is rather limiting).
 
Currently [proposed](https://github.com/mkruisselbrink/ServiceWorker/blob/foreign-fetch/foreign_fetch_explainer.md#what-about-cors) is that by default all responses from a foreign fetch handler should be opaque, and we'll have some extra API to explicitly mark a response as non-opaque (assuming the response isn't already opaque to the service worker itself). The proposed API allows you to associate two bits of information with a response: 

1. the origin to which the response should be exposed (similar to Access-Control-Allow-Origin in CORS, but not allowing wildcards), and
2. (optionally) which headers of the response should be exposed (similar to Access-Control-Expose-Headers in CORS)

Of course that leaves the question why we don't just require the foreign fetch handler to set these CORS headers on their responses, rather then coming up with our own API. I don't quite remember what the arguments for this were (changing headers requires returning a synthetic response, which might behave differently? slightly more complicated code to write to be able to return a synthetic response? semantics are subtly different from CORS so re-using CORS headers isn't ideal? explicit API is just easier to use?)

But assuming we do indeed want some kind of API to mark a response as being non-opaque for the purpose of foreign fetch, what should that API look like?

As proposed:
```idl
partial interface Response {
  static Promise<VisibleResponse> makeVisibleTo(promise<Response>,
      USVString origin, optional ResponseVisibilityOptions options);
};

dictionary ResponseVisibilityOptions {
  sequence<USVString> headers;
};

// TODO: define VisibleResponse
```
combined with changing `respondWith` to accept a `Promise<Response or VisibleResponse>` (for a regular fetch event calling makeVisibleTo on the response passed to respondWith wouldn't change any behavior).

The `makeVisibleTo` method could of course also be a method on the `FetchEvent` (and there is also the question if foreign fetch should keep using the same `FetchEvent` interface or have its own `ForeignFetchEvent` interface that might or might not derive from `FetchEvent`).

Another option might be to change `respondWith` to be able to be called asynchronously (as long as `waitUntil` promises haven't all resolved yet) and just add the new visibility options as an extra argument to respondWith.

/cc @slightlyoff @annevk 

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/841