[dotnet] Send data over cdp consecutively

[nvborisenko]

Description

According https://learn.microsoft.com/en-us/dotnet/api/system.net.websockets.websocket

Issuing multiple sends or multiple receives at the same time (for example, without awaiting, or from multiple threads without synchronization) is not supported and will result in an undefined behavior. Ensure that the previous operation is awaited (or completed) before issuing the next one. Serialize the access via whatever mechanism works best for you, for example, by using a lock or a semaphore.

Here we ensure that we allow to send data consecutively using SemaphoreSlim as synchronization context.

Motivation and Context

Fixes #10054

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[nvborisenko]

I didn't test it locally, my build is failing. Hopefully I can grab artifacts from CI and test it.

[nvborisenko]

Perfect, I was able to build locally with --stamp flag. This PR fixes the issue, verified locally.

[titusfortner]

@nvborisenko can you build selenium manager locally? That's the big difference between stamp and not stamp. @p0deje this is probably why we had it set that way in CI?

[nvborisenko]

I remember --stamp flag takes pre-build selenium manager, which allowed me to build modified C# code to verify my changes. Please ping me in chat, I will share all details you need about how build process works on my environment.

[p0deje]

@titusfortner Looking at https://github.com/SeleniumHQ/selenium/actions/runs/5942888108/job/16117259011?pr=12591 - this doesn't seem to be related to Selenium-Manager. @nvborisenko Did you get the same error locally?

[diemol]

Probably we should hold this and see if it is needed after merging #12614? What do you think, @nvborisenko?

[nvborisenko]

@diemol @jimevans
#12614 is merged, but I don't see protection of SendData method from concurrent use. There is still possibility to execute this method from different threads which leads to unpredictable behavior.

I think we should adopt this PR and move the protection to new WebSocketConnection class (or layer upper to DevToolsSession class?).

[nvborisenko]

Ok, I adopted it with the latest trunk. This PR is ready for review.

[titusfortner]

These failures have been determined to be an issue with how we are building the alert page for the test server, so I'm going to merge without these passing.