Summary of changes

• Removed static DiscoveryService.Instance in favour of instance on TracerManager
• Handle recreation and tear down of DiscoveryService when exporter settings change (i.e. config in code scenario)
• Redesign DiscoveryService to "subscription" model to handle dynamic changes in config.

Reason for change

This refactor handles three main issues in previous implementation

• The previous implementation would not honour config in code.
• Changes to the agent (e.g. it's upgraded while app is running) would not be honoured
• Harder to test in integration tests due to static state

Implementation details

IDiscoveryService is now implemented as:

internal interface IDiscoveryService
{
    void SubscribeToChanges(Action<AgentConfiguration> callback);
    void RemoveSubscription(Action<AgentConfiguration> callback);
    Task DisposeAsync();
}

If you need config, you call SubscribeToChanges() and pass in a delegate to be executed every time the config changes. If the intial config has already been fetched, this immediately executes the callback (I chose this approach over exposing the "current" AgentConfiguration on IDiscoveryService as it actually makes consuming config easier).

Updated existing usages of IDiscoveryService to the new pattern. This was simple for the StatsAggregator but a bit trickier for RCM and LiveDebugger, as they still need to be moved to TracerManagerFactory initialization (or similar). Nevertheless, I think this is an improvement

Test coverage

All existing tests (e.g. StatsTests etc) + unit tests for the DiscoveryService behaviour itself. As part of this, I extracted the TestApiRequestFactory helpers I've used elsewhere (and which I need in another branch too).

Other details

This is a requirement for the Data Streams Monitoring work. So as to not conflict with his changes, I've rebased this branch on top of @zacharycmontoya's PR and incorporated his changes: #3152