Expose the request's `mode' value

[arturjanc]

The request mode has five different values: same-origin, cors, no-cors, navigate, or websocket. Including its value in Sec-Metadata would have a few benefits:

• It would allow distinguishing navigation requests from subresource requests without checking destination for document and nested-document (checking for mode=navigate seems easier for developers).
• It more clearly identifies CORS requests (which the server can generally exempt from Sec-Metadata checks because there already must exist logic that checks the origin and sets the right ACA* headers). Currently these requests can be identified by looking for destination="" and the presence of an Origin header, which is somewhat clunky.
• It's likely more stable than the destination value. If developers write server-side checks based on a complete list of known values (which is a bad idea overall, but would be possible), then checking the mode could be less error-prone (e.g. if mode == "no-cors" && site != "same-origin": #reject).

Overall, it seems similar to the original idea of the target value (with the possible values of subresource, top-level or nested) but doesn't require introducing a new concept.

@mikewest

[arturjanc]

Note that we might still need the nested-document value in destination to distinguish between top-level and nested navigations (or we could expose this in another way).

[mikewest]

1. Sounds fine. Willing to write a patch?
2. As you note, we still need a mechanism to distinguish nestedness from non-nestedness. I'll go poke Consider splitting document into document and nested-document. whatwg/fetch#755.
3. As of 279d75c, destination="" is destination=empty.