Bug 1995691 made `emulation.setLocaleOverride` override the `Accept-Language` request header, but only for document-initiated requests.
Bug 2015655 made the locale override apply to the JS realm and `navigator.language` in `Worker` and `SharedWorker` but it did not touch the `Accept-Language` header or `WebSocket` path.
`HttpBaseChannel::Init` already applies the override centrally (via `AddStandardRequestHeaders`) from the loading `BrowsingContext`'s locale override, but `Worker` requests have no loading `BrowsingContext` so it never fired for them. `Init` now falls back to the associated `BrowsingContext` when the loading one is `null`.
For that fallback to work, the associated `BrowsingContext` has to be on the `LoadInfo` before the channel runs `Init`:
- `fetch()` now threads the associated `BrowsingContext` id through channel creation so it is set while the `LoadInfo` is constructed, instead of afterwards once the channel (and its request headers) already exist.
- The `WebSocket` handshake now reuses the `WebSocket`'s own `LoadInfo` (which already carries the association) via a new `nsIIOService::newChannelFromURIWithProxyFlagsAndLoadInfo`, rather than synthesizing a fresh `LoadInfo` that dropped it.
Leaning on the central path lets both manual `Accept-Language` `SetRequestHeader` blocks go away, and also covers `Worker` `XMLHttpRequest` for free.
Differential Revision: https://phabricator.services.mozilla.com/D310690
Devin Rousso
a043907285