Redesign "extract header values" and "extract header list values"

[annevk]

These APIs had the wrong design and are also incorrectly used at times (#559). "Extract a MIME type" also needs a new design, likely on top of this as a new Content-Type parser: #529.

In particular, other than for Set-Cookie the ideal way to parse a header is to combine first, and then parse, which isn't really what the current operations are doing. How to combine headers is nearly settled: #813. Once that's done my tentative plan is to introduce a new "get" for header lists to solve #752 which would return null or the combined value for a given header name from a header list.

Another problem with the current setup is that the actual parsing is handwavy by referencing ABNF defined "somewhere", which in practice leads to it being poorly tested. We can continue to allow ABNF for headers where that is actually how they are implemented, but we need to be more strict about referencing the ABNF and writing the tests and not allowing as much indirection as is currently allowed for.

Unfortunately this will impact downstream, but I think it's the right thing to do long term and will lead to better considered header parsers (and encourage more reuse as well). I'll also start filing downstream issues now linking this issue to ensure we actually design something that works for everyone.

So I think what we want is basically "get" and then per header name we'll need to define its parser (which could just be an ANBF reference plus tests) or parsers (Content-Type differs between request and response, yay). Thoughts on the details here appreciated as well as on the overall plan of course.

[annevk]

In #818 @mikewest suggested that perhaps it'd be useful if there was a way to always get the "string" value from a header. So basically "get" on a header list and then return the result of isomorphic decoding that (if non-null). We could add "get as string" for this provided there's more than one consumer, which seems likely if we'll continue to define most parsers on top of strings.

[annevk]

Things to define anew within Fetch (and test) to get rid of "extract header values":

• CORS Content-Type (CORS-safelisted request-header; see Be strict on request's Content-Type #829 for a patch)
• request DPR/Downlink/Save-Data/Viewport-Width/Width (CORS-safelisted request-header)
• X-Content-Type-Options (see Define parsing for X-Content-Type-Options in detail #818 for a patch)

For "extract header list values":

• Content-Type (see Content-Type parsing (MIME type parsing) mimesniff#30, Define the Content-Type header parser #831)
• Access-Control-Expose-Headers (Defining Access-Control-Expose-Headers parsing #827)
• Location (Preventing some CRLF header injection attacks #375, Location header is the empty string #669, URL parser called with byte sequence #843, Handling of invalid Location header characters doesn't match browsers #883)
• Content-Encoding (see Remove Gecko-only quirk #816 for removing a quirk, Content codings (Content-Encoding) #716 for the remainder)
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Max-Age ([Gecko Bug 1607615] Allow CORS preflights with a default of 5 seconds for expiry if Access-Control-Max-Age hasn't been sent web-platform-tests/wpt#21170 might help)
• Access-Control-Allow-Origin and Access-Control-Allow-Credentials (should be a literal match on the return of a "get" defined by Define parsing for X-Content-Type-Options in detail #818; see Refactor the CORS check #824 for a patch)
• Sec-WebSocket-Protocol (#515)

[annevk]

There's also headers that maybe should be defined in Fetch (or HTTP if it wants to tackle error handling):

• Content-Length: Define Content-Length parser #1183
• WWW-Authenticate: Fetch/HTTP: test WWW-Authenticate parsing web-platform-tests/wpt#13189

(I might end up tracking these separately though as these would be additions rather than refactoring the status quo.)

[annevk]

In HTML:

• Refresh Multiple Refresh headers html#2900