[browser][mt] Thread affinity for HTTP and WS

[pavelsavara]

Keep HTTP and WS on the same thread where it was initiated in the browser.
Because the JavaScript objects and the network sessions are bound to particular web worker.

Luckily the OperatingSystem.IsBrowser() is a constant and so it should be eliminated by IL linker or JIT.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Keep HTTP and WS on the same thread where it was initiated in the browser.
Because the JavaScript objects and the network sessions are bound to particular web worker.

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-System.Net.Http
Milestone:	8.0.0

[campersau]

Do these HttpContent implementations also need to be updated?
https://github.com/dotnet/runtime/tree/main/src/libraries/System.Net.Http.Json/src/System/Net/Http/Json

[pavelsavara]

Do these HttpContent implementations also need to be updated? https://github.com/dotnet/runtime/tree/main/src/libraries/System.Net.Http.Json/src/System/Net/Http/Json

Good point. It spreads to all corners actually.
Anything that could call and await HTTP or WS need to have it.
Anything that awaits Stream needs to have it too, as the stream could be HTTP stream.

Even our unit tests have ConfigureAwait(false) for some reason.

Is there better way ?

[lambdageek]

@pavelsavara I tried this in #85109 and it's enough to get the Blazor Weather Report page to fetch its data correctly.

But we probably need to solve this in another way. Changing all the ConfigureAwait(false) everywhere isn't going to be sustainable. And it will miss other mechanisms that push work off to other threads.

We will probably need to do something to queue the JS invoke on the correct thread under the covers.