[wasm-ep] Configure the Diagnostic Server using DOTNET_DiagnosticPorts

[lambdageek]

In order to make diagnostics work with Blazor, we need to provide a mechanism that works with their WebAssebly startup sequence (near here: MonoPlatform.ts). Using a MonoConfig diagnostic_options section doesn't work because they don't have this object. Additionally the current call to mono_wasm_init_diagnostics is in mono_wasm_before_user_runtime_initialized which is not called for Blazor.

The other constraint is that mono_wasm_init_diagnostics is async (because it waits for the DS thread to start), so we need to call it during an async part of runtime startup.

---

So the task is:

1. Use the DOTNET_DiagnosticPorts environment variable to configure the diagnostic server - similar to desktop. Setting it to a value like ws://127.0.0.1:8088/diagnostics,connect,suspend will cause the runtime to connect to the given WebSocket URL and suspend until a diagnostic tool sends a resume command. We will only support connect, not listen (which is not meaningful for a websocket). We will support suspend (the default) and nosuspend
2. Blazor can setenv DOTENT_DiagnosticPorts from their onRuntimeInitialized callback
3. Move the call to await mono_wasm_init_diagnostics() to mono_wasm_after_user_runtime_initialized which is async and runs after onRuntimeInitialized but before we call Blazor's postRun (which calls MONO.mono_wasm_load_runtime which is a sync function that actually begins running our C code - ie we must have the diagnostic server running by this point)

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

Issue Details

---

In order to make diagnostics work with Blazor, we need to provide a mechanism that works with their WebAssebly startup sequence (near here: MonoPlatform.ts). Using a MonoConfig diagnostic_options section doesn't work because they don't have this object. Additionally the current call to mono_wasm_init_diagnostics is in mono_wasm_before_user_runtime_initialized which is not called for Blazor.

The other constraint is that mono_wasm_init_diagnostics is async (because it waits for the DS thread to start), so we need to call it during an async part of runtime startup.

---

So the task is:

1. Use the DOTNET_DiagnosticPorts environment variable to configure the diagnostic server - similar to desktop. Setting it to a value like ws://127.0.0.1:8088/diagnostics,connect,suspend will cause the runtime to connect to the given WebSocket URL and suspend until a diagnostic tool sends a resume command. We will only support connect, not listen (which is not meaningful for a websocket). We will support suspend (the default) and nosuspend
2. Blazor can setenv DOTENT_DiagnosticPorts from their onRuntimeInitialized callback
3. Move the call to await mono_wasm_init_diagnostics() to mono_wasm_after_user_runtime_initialized which is async and runs after onRuntimeInitialized but before we call Blazor's postRun (which calls MONO.mono_wasm_load_runtime which is a sync function that actually begins running our C code - ie we must have the diagnostic server running by this point)

Author:	lambdageek
Assignees:	lambdageek
Labels:	arch-wasm, area-Diagnostics-mono
Milestone:	7.0.0

[lewing]

cc @radical @javiercn

[lambdageek]

Turns out we have to init diagnostics in two differnet places because blazor and non-blazor startup will set environment variables in two different codepaths

• for Blazor, init diagnostics after their onRuntimeInitalized sets env variables, but before their postRun callback (which calls mono_wasm_load_runtime)
• for non-Blazor, init diagnostics in _apply_configuration_from_args - which sets environment variables - and which is called from mono_wasm_before_user_runtime_initialized just before mono_wasm_load_runtime