[browser] eager allocation of Promise/Task result for async JSImport/JSExport

[pavelsavara]

Motivation

"Because the caller already knows they need to create a proxy-promise, which would be later bound to result of the called function."

This makes it possible to send marshaling "stack frame" of async JSImport/JSExport methods as one-way message.
Because Promise/Task result is created by sender thread ahead of time and sending thread could await it even before receiving thread saw the message.

This PR doesn't contain the MT changes which will use this.

Summary

PR #93648 introduced virtual GC and JS handles.
They are good because we could allocate the handle to the future object of the other side, without crossing to that other side to create the real object. That matters in MT scenarios, in which we also need to cross to the correct thread.

This PR optimizes it further by allocating the real PromiseHolder or TaskHolder and normal non-virtual handle for it.
We do it for the return value of async JSImport or JSExport.

The Task/Promise passed as parameter keep using the virtual handles.
"Because we only need to pass virtual identity of the proxy-promise which will be created on the other side".

We still support case when target method returns synchronously resolved Task/Promise or null. Only when caller invokes the JSImport/JSExport synchronously. Which is currently always.

null value and synchronous resolve/reject would not be possible return value of real async cross-thread MT dispatch. There are currently WS client scenarios which are using synchronous null as signal. That would need to be fixed on another PR.

Changes

• pre-allocate PromiseHolder for async JSImport in InvokeJSImportImpl
• rename CreateJSOwnedHolder to GetPromiseHolder
• renames back from gcvHandle to gcHandle where both could be used
• rename InvokeJSImpl to InvokeJSFunction
• rename mono_wasm_invoke_bound_function to mono_wasm_invoke_js_function
• use OwnerTID in JSObject instead of ManagedThreadId
• make JSObject.Dispose asynchronously Posted to thread of affinity.
• added async methods to the advanced sample

[ghost]

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

Issue Details

---

Motivation

This makes it possible to send marshaling "stack frame" of async JSImport/JSExport methods as message.
Because Promise/Task result is created by sender thread ahead of time and sending thread could await it even before receiving thread saw the message.

This PR doesn't contain the MT changes which will use this.

Summary

PR #93648 introduced virtual GC and JS handles.
They are good because we could allocate the handle to the future object of the other side, without crossing to that other side to create the real object. That matters in MT scenarios, in which we also need to cross to the correct thread.

This PR optimizes it further by allocating the real PromiseHolder or TaskHolder and normal non-virtual handle for it.
We do it for the return value of async JSImport or JSExport.
The Task/Promise passed as parameter keep using the virtual handles.

This supports case target method synchronously returns null Task/Promise, only when caller invokes the JSImport/JSExport synchronously. Which is currently always.

Changes

• pre-allocate PromiseHolder for async JSImport in InvokeJSImportImpl

• rename CreateJSOwnedHolder to GetPromiseHolder

• renames back from gcvHandle to gcHandle where both could be used

• rename InvokeJSImpl to InvokeJSFunction

• rename mono_wasm_invoke_bound_function to mono_wasm_invoke_js_function

• use OwnerTID in JSObject instead of ManagedThreadId

• make JSObject.Dispose asynchronously Posted to thread of affinity.

• added async methods to the advanced sample

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript, 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).

[kg]

Other than my comments I don't see anything blocking this, but I don't feel confident at all in my understanding of jsv/gcv vs js/gc handles or the correctness of the code using them

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

There is unrelated System.Collections.Concurrent.Tests in WASM MT.