[dotnet] Added function to enable halting targets until runtime.runIfWaitingForDebugger is invoked

[EdwinVanVliet]

Description

This PR introduces EnableWaitForDebuggerOnStart function to DevToolsSession.cs which enables halting new targets (tabs for instance) until the runtime.runIfWaitingForDebugger command is invoked. For instance when wanting to capture the network traffic on a new target, the network domain should be instructed to do so before the target is doing any network traffic.

In PR #13175 the datastructure for listening to the TargetAttached events was introduced.

In a follow up pull request I will introduce the ability to sent multiple DevTools commands in a single SendCommand function. This will allow proper handling of the TargetAttached event. The singular SendCommand function will get blocked because the commands running against that target will be blocked until runtime.runIfWaitingForDebugger is invoked. By bundling the commands we can get around that issue.

Also see; #10603

Motivation and Context

When a new target (new tab for instance) is created DevTools continues execution based on the WaitForDebugger property set in the SetAutoAttach feature. When the WaitForDebugger property is set to false DevTools continues without waiting the consumer to properly enable all domains on the target. For instance when being interested in network events from the network domain we need to invoke Network.enable for that specific target. The current behavior causes some of the network events to be missing due to Selenium enabling the domains after the target already performed network requests.

By allowing consumers to enable the WaitForDebugger property we can enable all domains and tell DevTools whenever we are ready by using the Run.runIfWaitingForDebugger command.

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]

Looks good to me, thank you @EdwinVanVliet . Last ask: can we create at least one test which demonstrates how to use this new feature in area of capturing network requests in newly opened browser tab?

[EdwinVanVliet]

@nvborisenko

Sounds like a good idea, however with current setup that's not possible yet. When halting the tab an event is raised indicating a new target is created. To continue that target at least two commands need to be issued (runtime.runIfWaitingForDebugger and Network.enable). The problem here is that command will be blocked until runtime.runIfWaitingForDebugger is invoked.

To workaround that we sent the commands in one batch without blocking each other. That will be introduced in the following PR and I will try to add a test case demonstrating the behavior with that.

[nvborisenko]

Thanks @EdwinVanVliet , looking forward your contribution.