Explicitly provide the "Origin" header on session establishment

[yutakahirano]

Use |transport|'s relevant settings object's origin.

Fixes #368.

---

Preview | Diff

[yutakahirano]

@zcorpan can you take a look?

[zcorpan]

LGTM, thanks!

[zcorpan]

For web-platform-tests, you can test this (verify that the origin comes from the right environment settings object) by using the same pattern as one of these:

$ find . -name "multi-globals"
./websockets/multi-globals
./html/cross-origin-embedder-policy/multi-globals
./fetch/api/response/multi-globals
./fetch/api/request/multi-globals
./workers/multi-globals
./webmessaging/multi-globals
./service-workers/service-worker/multi-globals

The websockets tests can be used as a basis for which globals to include in the test, since it also uses a constructor.

However, here we'd want to test the value of the Origin header, and so the entry page should be a different origin from the other pages. That means you have to use subdomains, and use document.domain to opt-in to DOM access.

[yutakahirano]

We have a test ('Echo back request headers') in https://github.com/web-platform-tests/wpt/blob/master/webtransport/connect.https.any.js.

[zcorpan]

Nice, though it doesn't seem to exercise multiple globals and the possibility of the browser advertising the origin of the wrong environment settings object (e.g. incumbent settings object instead of the relevant settings object).

I don't think such a test needs to block this PR, though.