Implement headers.getSetCookie()

[jasnell]

Implementation of the proposed headers.getSetCookie() API

The API is still not 100% finished so we likely don't want to land just yet. Deno folks have asked (through wintercg) if we could coordinate on the release of this so that it hits multiple runtimes at the same time, allowing us to get a bit more of a bang-for-the-buck announcing the common API. The spec change has landed, this should be just about ready to go.

Note: this is potentially a breaking change due to the change in the way the iterator is handled. Previously, our iterator would inappropriate munge set-cookie headers together. This change separates them properly for both entries() and values(). Do we need a compatibility flag tor this behavior change? Added a compatibility flag

Refs: whatwg/fetch#1346

[jasnell]

/cc @lucacasonato

[harrishancock]

This change separates them properly for both entries() and values().

The linked Fetch spec PR appears to also require us to change keys(), I think.

Specifically, the linked PR redefines the "sort and combine" operation to produce a list like (in JSON-ish pseudocode) [{ key: "set-cookie", value: "value0" }, { key: "set-cookie", value: "value1" }].

The "sort and combine" operation is used in exactly one place: to produce the "value pairs to iterate over". Thus, the "value pairs to iterate over" are a list of header names and values, with potentially-duplicate names.

In Web IDL, all four iteration methods (keys(), values(), entries(), and forEach()) are implemented generically in terms of this list of "value pairs to iterate over". My reading of the implementation suggests we're not supposed to be de-duplicating the keys, which means our current Headers::keys() implementation would be non-conformant.

Do we need a compatibility flag tor this behavior change?

I would err on the side of yes, though I don't have a particularly compelling problem scenario.

[jasnell]

The linked Fetch spec PR appears to also require us to change keys(), I think.

@lucacasonato ... can you confirm if this is intentional? It seems odd that the keys() iterator may not be unique.

[lucacasonato]

Mh, this is an interesting case. Can you comment on the spec PR?

[harrishancock]

LGTM; remember to squash.

[jasnell]

Just waiting on the spec change to land upstream before landing.

[jasnell]

@harrishancock ... updated to add the compat flag, which meant also having to update the JSG_ITERATOR macro and the various places it is used. Can I ask you to take another look?

[harrishancock]

It LGTM, though I agree with Kenton that we could probably just delegate from getAll() to getSetCookie().

[jasnell]

Updated to delegate getAll to getSetCookie, also squashed and rebased for a final CI run.