…ttings (#7695)

## Summary of changes

- Introduces `SettingsManager` responsible for managing
`MutableSettings` and `ExporterSettings`

## Reason for change

We need to be notified about runtime changes to settings (i.e. config in
code or remote config) but don't want to tear down the world and rebuild
every time. `SettingsManager` is responsible for handling this.
Consumers subscribe to changes and can be notified about updates.

This is a first step which just introduces the type, but doesn't force
users to consume changes or remove the current places settings are
exposed. Instead, it just encapsulates the changes.

## Implementation details

- Introduce `SettingsManager`
- Move code duplicated in `DynamicConfigurationManager` and
`ConfigureIntegration` into `SettingsManager`
- Create a new instance of `SettingsManager` (and maintain it throughout
the app lifetime)
- Subscribe to changes one time in `TracerManager` to do the "full
rebuild"
- This is a stop gap before we use it "properly" and stop exposing the
settings on `TracerSettings`

## Test coverage

- Mostly a refactor so covered by integration tests
- Unit tests for `SettingsManager` functionality

## Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-819

Part of a config stack

- #7522
- #7525
- #7530
- #7532
- #7543
- #7544
- #7721
- #7722
- #7695 👈
- #7723
- #7724
- #7796

---------

Co-authored-by: Lucas Pimentel <lucas.pimentel@datadoghq.com>

… config changes (#7796)

## Summary of changes

A fix for #7724 to handle telemetry reporting in dynamic config "reset"
scenarios

## Reason for change

The system tests for #7724 were failing in some dynamic configuration
scenarios. Specifically, the tests were sending remote config _without_
any configuration values "i.e. 'reset to use defaults'" and were waiting
a telemetry update. However, we never sent it, because there was "no
telemetry to record".

Note that we _did_ correctly apply the new configuration, we just didn't
report the telemetry correctly, primarily due to limitations in the
telemetry protocol. This PR adds a fix for that, and will be merged into
#7724.

## Implementation details

The solution is to "remember" the telemetry from the default mutable
configuration values, _without_ any dynamic sources, and "replay" this
telemetry when we update telemetry. This feels kind of hacky, but it's
something I suspected we might need to do, and had been avoiding up to
this point because we do a "full reconfigure" anyway.

## Test coverage

Added a specific unit test that mimics the behaviour of the system-test
(i.e. an "empty" dynamic config response) and confirms the telemetry is
recorded as expected

## Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-819

Part of a config stack

- #7522
- #7525
- #7530
- #7532
- #7543
- #7544
- #7721
- #7722
- #7695
- #7723
- #7724
- #7796 👈

Unlike other PRs in the stack, I'll merge this directly into #7724 to
fix the tests there, just thought I'd keep this separate for easier
reviewing

## Summary of changes

- Fix broken `master` due to concurrent merges of conflicting 

## Reason for change

#7698 moved to defining references in yaml, and in #7723, some of those
references moved, which broke the build

## Implementation details

Update the YAML file and rebuild

## Test coverage

If it builds, we're good!

… config changes (#7796)

## Summary of changes

A fix for #7724 to handle telemetry reporting in dynamic config "reset"
scenarios

## Reason for change

The system tests for #7724 were failing in some dynamic configuration
scenarios. Specifically, the tests were sending remote config _without_
any configuration values "i.e. 'reset to use defaults'" and were waiting
a telemetry update. However, we never sent it, because there was "no
telemetry to record".

Note that we _did_ correctly apply the new configuration, we just didn't
report the telemetry correctly, primarily due to limitations in the
telemetry protocol. This PR adds a fix for that, and will be merged into
#7724.

## Implementation details

The solution is to "remember" the telemetry from the default mutable
configuration values, _without_ any dynamic sources, and "replay" this
telemetry when we update telemetry. This feels kind of hacky, but it's
something I suspected we might need to do, and had been avoiding up to
this point because we do a "full reconfigure" anyway.

## Test coverage

Added a specific unit test that mimics the behaviour of the system-test
(i.e. an "empty" dynamic config response) and confirms the telemetry is
recorded as expected

## Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-819

Part of a config stack

- #7522
- #7525
- #7530
- #7532
- #7543
- #7544
- #7721
- #7722
- #7695
- #7723
- #7724
- #7796 👈

Unlike other PRs in the stack, I'll merge this directly into #7724 to
fix the tests there, just thought I'd keep this separate for easier
reviewing

…building (#7724)

## Summary of changes

- This is the big one
- Update services to dynamically update when mutable settings or
exporter settings change
- Stop rebuilding everything when there's manual/remote configuration

## Reason for change

This is the "endpoint" that we've been heading for - services only being
disposed/rebuilt at the end of the app, and otherwise only rebuilding
the _necessary_ parts. For example - we don't need to tear down all the
API factories when a customer changes a global tag via remote config;
they only need to change if the `ExporterSettings` change.

The hope is that overall this reduces the overhead of using
configuration in code and/or remote configuration, while also reducing
the number of issues due to managing disposal of services.

## Implementation details

Overall, this PR is kind of a pain. Moving from the "rebuild everything"
to "reconfigure each service" couldn't be done piecemeal, so this is the
one-shot PR. What's more, different services need different patterns
(though we can probably consolidate some of them, this has taken a _lot_
of work and I likely changed patterns unnecessarily in some places).

In general, there's a couple of patterns:

- CI Vis doesn't let you change settings at runtime, so it _never_ needs
to respond to changes. It always just uses the "initial" settings
- Debugger _today_ doesn't respond to changes at runtime (except its own
dynamic config), so for now we ignore Debugger too as it's not really a
regression. I hope we can fix this soon though.
- I've introduced the concept of `Managed*` versions of some services
- These services generally "wrap" the existing type, delegating access
to the underlying service, and handling settings changes
- Many services only care about a sub-set of mutable settings, so they
only update if they need to
- Somewhat annoyingly, setting updates occur on a background thread, so
we need to be careful about thread safety. Where necessary (most places)
I've made sure access to a now-mutable service is done using
`Volatile.Read()` (to ensure changes are visible) and are generally
cached to a local variable (as the underlying field may be updated in
the background).

## Test coverage

In the vast majority of places, this should be covered by existing tests

I plan to add some additional integration tests around reconfiguring and
a bunch of manual testing to make sure I'm confident.

## Other details

I strongly recommend reviewing commit-by-commit. They're generally
self-contained, and hopefully simple enough to understand one commit at
a time.

https://datadoghq.atlassian.net/browse/LANGPLAT-819

Part of a config stack

- #7522
- #7525
- #7530
- #7532
- #7543
- #7544
- #7721
- #7722
- #7695
- #7723
- #7724 👈
- #7796

This isn't the final PR in the stack, as there will be a bunch of
cleaning up to do, but it's the final "implementation" PR

## Summary of changes

Updates a couple of places where we're calling `Tracer.Instance` where
we don't need to

## Reason for change

In one of my other PRs I accidentally broke something that should _only_
have affected integration tests, but a bunch of unit tests broke. It
highlighted where they were using `Tracer.Instance` and setting the
global tracer for tests. In other places, it revealed that code that
tests that _looked_ independent of other tests really wasn't...

Calling `Tracer.Instance` potentially does a _lot_ of work, as it
initializes the tracer. It's also hard to follow if we're making static
calls out in places we don't need to. So just pass through the settings
we want instead.

## Implementation details

Instead of calling `Tracer.Instance.Settings`, use the value of `Tracer`
or `TracerSettings` that's already available wherever possible. It makes
the tests cleaner too.

## Test coverage

Same coverage, just a bit cleaner 

## Other details

Included as part of the config stack, just because I already refactored
some of this code, and can't be bothered to faff with merge conflicts:

https://datadoghq.atlassian.net/browse/LANGPLAT-819

- #7522
- #7525
- #7530
- #7532
- #7543
- #7544
- #7721
- #7722
- #7695
- #7723
- #7724
- #7744 👈