Support resetting state when connecting to a previously monitored app

[wiktork]

Summary

Scenario
Dotnet-monitor profiling/exceptions/parameter capture is installed in an application. Then dotnet-monitor is terminated but the application is not. Dotnet-monitor is then restarted and is once again observing the same application.

Startuphook/profiler changes

• Startup hooks only install once. This behavior has been maintained.
• Profiler previously attempted to install again. We now detect that a profiler is already installed and reuse that channel.

Command handling
There are 3 threads that handle commands:

• The connection thread, listening for a connection with the client. The message is processed and dispatched as appropriate:
• For a simple message such as callstack collection, the message is sent to the native queue.
• For startup hook messages (such as exceptions/parameter capture), the message is sent to the managed queue to be picked up by the startup hook for further processing
• The new reset message. This message sends stop/start messages to the native and managed queues above. These effectively block until a response is received from the stop calls to ensure that all cached data has been cleared.

Exception reset

• Exceptions rely on an event handler and occur synchronously on any thread.
• For stopping, we first unhook from the exception handler. Then we synchronously wait for all outstanding exception processing to finish. Note the client is awaiting these operations to finish and will not finish the profiler initialization until then.
• After all the data drained, we reset the pipelines and attach the event handler.

Parameters capture reset

• We request that all outstanding requests are turned off. No further synchronization is necessary because parameter capturing has a concept of RequestId that matches up requests with returned data. So if a new client received old data, it simply discards it.

Callstacks

• No action is needed, but we could further optimize by cancelling outstanding stack walks.

TODO:

• Figure out a way to call stop when the client is disconnected and no new client is started.
• Ideally this can be used for independent stop/start calls in the future. However, this will require additional changes to the client for exceptions.
• Add tests for reset scenario.

Release Notes Entry

Added support for resetting in process features when dotnet-monitor is restarted.

[schmittjoseph]

Signing off on the parameter capturing + profiler changes. Be sure to add a release notes entry and the relevant PR label