[browser][mt] dynamic thread create

[pavelsavara]

• changed default available pool size from 40 to 5, but floating, not just at the start
• remove explicit <_WasmPThreadPoolSize> from project files
• set PTHREAD_POOL_SIZE_STRICT=0 which will not throw when we run out of thread pool threads, but it will allocate more.
  • if you are lucky, the pool will always have some loaded threads
  • if you are less lucky, but still your main thread is serving the event loop, threads will be created on demand and used
  • if you block UI event loop, you will eventually run out of the pool and deadlock. This is "sorry, don't do that"
• replaced emscripten's getNewWorker internal and use it to trigger adding more to the emscripten's thread pool.
• simplified acquisition and replacements in Module's PThread internal
• rename WebWorker to JSWebWorker
• cleanup JSWebWorker
• add await JavaScriptImports.ThreadAvailable to JSWebWorker so that we are sure that the pthread is ready/loaded
• remove workers which were used as JSWebWorker from the pool, because they have dirty JS state

[ghost]

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

Issue Details

---

• set PTHREAD_POOL_SIZE_STRICT=0 which will not throw when we run out of thread pool threads, but it will allocate more.
  • if you are lucky, the pool will always have some loaded threads
  • if you are less lucky, but still your main thread is serving the event loop, threads will be created on demand and used
  • TODO: currently our Xunit runner is not yielding and so it will deadlock
• changed default available pool size from 40 to 3, but floating, not just at the start
• replaced emscripten's getNewWorker internal and use it to trigger adding more to the emscripten's thread pool.
• simplified acquisition and replacements in Module's PThread internal
• rename WebWorker to JSWebWorker
• cleanup JSWebWorker
• add await JavaScriptImports.ThreadAvailable to JSWebWorker so that we are sure that the pthread is ready/loaded
• adding System.Runtime.InteropServices.JavaScript.Tests as MT smoke test
• remove explicit <_WasmPThreadPoolSize> from project files

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-VM-threading-mono, os-browser
Milestone:	9.0.0

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).