[release/6.0] [wasm][debugger] Fixing the race condition while modifying pending_ops

[thaystg]

Fixing the race condition, modifying pending_ops, as discussed here:
#76900

Fixes: #68402

Backport of fdc0d16 to release/6.0

Customer Impact

There isn't a easy way to reproduce it, but the customer is debugging his app, then suddenly this error message is showed, and the debugging session is aborted, the customer needs to start the app again to continue debugging.
fail: Microsoft.WebAssembly.Diagnostics.DevToolsProxy[0] DevToolsProxy::Run: Exception System.ArgumentException: The tasks argument included a null value. (Parameter 'tasks') at System.Threading.Tasks.Task.WhenAny(Task[] tasks) at Microsoft.WebAssembly.Diagnostics.DevToolsProxy.Run(Uri browserUri, WebSocket ideSocket)
There was a racing condition while adding and removing items from pending_ops, that is the list with the messages which were sent from the BrowserDebugProxy, @radical refactored this code and now it's using ChannelWriter and ChannelReader to avoid this racing condition on the pending_ops list.

Testing

Manually tested.

Risk

Low risk, applying a change that is already landed on .net7.

IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

[ghost]

Tagging subscribers to this area: @thaystg
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixing the race condition, modifying pending_ops, as discussed here:
#76900

Backporting: fdc0d16

Author:	thaystg
Assignees:	-
Labels:	area-Debugger-mono
Milestone:	-

[thaystg]

@lewing @radical if you think this makes sense please let me know. Then I can send the email to tactics.

[lewing]

Active customer issue on LTS with a well tested fix, makes sense to me if you're confident in the backport.

[carlossanlop]

Approved by Tactics (7.0.3).
Signed off by area owner.
No OOB changes needed (wasm).
CI failures:

• The browser legs are failures when attempting to cancel after reaching the timeout. @thaystg do you think they could be related? Do you want to re-run?
• OSX failure is known/unrelated: [6.0] Test failures on OSX: OSVersion_ValidVersion_OSX, CurrencyNegativePattern_Get_ReturnsExpected_ByLocale #80252
• MacCatalyst is known/unrelated, and a fix was merged shortly after this PR was created, hence why it hit it: [release/7.0] Workaround MacCatalyst .app output path change in cmake 3.25 #79097
• tvOS, Android, iOS are warnings, unrelated.

[thaystg]

The wasm failure is not related to the PR. The debugger-tests I ran locally and they are passing.

[carlossanlop]

Thanks for checking. Let's get this merged.

[mwasson74]

Hello, @thaystg!! I do not know the correct terminology to use but how can I tell which version of .NET 6 and when this will be released to the public?

Thank you!!

[carlossanlop]

@mwasson74 Version 6.0.14 will contain this fix, which is the February Servicing Release.

[mwasson74]

Excellent, thanks so much @carlossanlop!! I saw the milestone was .NET 7 and wasn't sure if it was on the right "track" to being released to a new .NET 6 version.

[carlossanlop]

Apologies. I applied the wrong milestone but it's corrected now.