## Summary of changes

Don't pass a `Tracer` instance to `PerTraceSettings.GetServiceName()`
(as it's not required)

## Reason for change

Cleanup/simplify the code.

#7530 exposes `MutableSettings` and `DefaultServiceName` on
`PerTraceSettings`. Reading `DefaultServiceName` was the only reason
`GetServiceName()` took a `Tracer`, so this is now uneccessary.

## Implementation details

- Use `MutableSettings.DefaultServiceName` directly inside
`PerTraceSettings.GetServiceName()`
- Stop passing in `Tracer` instance
- Cleanup usages

## Test coverage

Covered by existing, just a refactoring

## Other details

Could have done it as part of #7530 but trying to keep things small!

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

Part of a config stack

- #7522
- #7525
- #7530
- #7532 👈
- #7543
- #7544

…ropriate (#7543)

## Summary of changes

Fix usages of `Tracer.Instance.Settings` to use
`Tracer.Instance.CurrentTracerSettings.Settings` where appropriate

## Reason for change

This PR "fixes" the places that were previously grabbing the
environment/service etc from `TracerSettings` to use the
`MutableSettings` exposed via `CurrentTracerSettings` instead, as the
location where these settings will ultimately exist.

This is effectively still just a refactoring, but prepares for the point
where these settings aren't exposed on `TracerSettings` at all. The
updates in this PR are for cases where you _don't_ have long-lived
services, and rather need to do ad-hoc `Tracer.Instance` grabbing of the
setting values in a global context. Note too that many of these places
_could_ be updated in the future to subscribe to changes if that
provides performance benefits. Also note that I elected not to change
most calls to `IsIntegrationEnabled()` etc in this PR as there are
hundreds of locations. The follow up PR handles that

Also found a few cases that were incorrectly assuming that these values
cannot change. Marked them with 'TODO: Subscribe to changes in settings'

## Implementation details

- Mostly find and replace to use `CurrentTracerSettings.Settings`
- Occasional extraction of a variable where it makes sense to avoid
repeated access
- Functionally identical currently (where `MutableSettings` is replaced
on `TracerSettings`) but will be a required change once we stop
replacing `TracerManager`.

## Test coverage

Covered by existing tests

## Other details

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

Part of a config stack

- #7522
- #7525
- #7530
- #7532
- #7543 👈
- #7544

…tIntegrationAnalyticsSampleRate()` (#7544)

## Summary of changes

Fix usages of `IsIntegrationEnabled()`, `IsErrorStatusCode()`, and
`GetIntegrationAnalyticsSampleRate()` to use `MutableSettings` instead
of `TracerSettings`

## Reason for change

These functions are dependent on `MutableSettings`, and are exposed
there, so making sure we call the methods there, and remove the
delegation from `TracerSettings` entirely.

## Implementation details

- Find and replace usages
- Remove the old delegating methods

## Test coverage

Just a refactor, so covered by existing tests

## Other details

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

Part of a config stack

- #7522
- #7525
- #7530
- #7532
- #7543
- #7544 👈
- #7695

…ndows (#7721)

## Summary of changes

Enforces that you can't _change_ the `AgentUri` to be a UDS Uri if
you're on Windows

## Reason for change

The trace exporter doesn't work with UDS on Windows, so we have a check
in `TracerSettings` that disables the pipeline if we find this scenario.
However, user's can still _change_ the agent URI at runtime in code (😭).

We currently assume that the data pipeline won't be toggled at runtime
(we _do_ allow for reconfiguring it in general, but not for completely
removing or reintroducing). Changing this to allow the scenario would be
a pain, so instead this PR blocks you from setting a UDS URI in code if
you're on Windows.

The good news is that as far as I can tell, noone does this today, so
while _technically_ it could be considered a breaking change, I think
it's ok.

## Implementation details

- Throw an `ArgumentException` in the Datadog.Trace.Manual library, if
you're on Windows (or .NET FX) and you try to set a UDS agent URI (using
the same "detection" we do in `ExporterSettings`.
- Add a check in the Instrumentation of `Tracer.Configure()` to make
sure it hasn't slipped through. This could happen if a customer was
using an old version of the Datadog.Trace NuGet package with a newer
version of auto instrumentation.

Note that this adds two additional framework references for .NET Core
3.1+, to check if we're on Windows.

## Test coverage

Added an extra step to the manual instrumentation integration test to
confirm we throw

## 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

## Summary of changes

Add a helper for comparing `ReadOnlyDictionary<>` instances

## Reason for change

As part of the config work, we need to detect if tags have changed when
customers do a manual/remote config update. This helper makes it easy

## Implementation details

Added a `SequenceEqual` extension method.

Note that I used `SequenceEqual` because it _already_ exists in
_System.Linq_, but I could see an argument that it's too easy to use the
wrong one, and instead we could use a different name? `IsSameAs(other)`?

Also, I only wrote this for `ReadOnlyDictionary<>` because that's all we
need, it's what we use for all our setting dictionaries, and it will be
(a tiny bit) faster than making it `IDictionary<>`, but happy to change
if people feel strongly.

## Test coverage

Added unit tests

## 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

---------

Co-authored-by: Steven Bouwkamp <steven.bouwkamp@datadoghq.com>

…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>

…7723)

## Summary of changes

Instead of exposing settings like `ServiceVerion` and `Environment` on
`TracerSettings`, only expose them on `MutableSettings`

## Reason for change

This is all part of the refactoring towards having `TracerSettings`
being an immutable settings object, that's created once on app startup,
and fixed for the lifetime. `ServiceVerion` and `Environment` currently
delegate to the `MutableSettings` object stored on `TracerSettings`, but
are going to move that elsewhere shortly so that consumers can subscribe
to changes

## Implementation details

For this PR, it's just a case of changing `TracerSettings.XXX` =>
`TracerSettings.Mutable.XXX`. A future PR will then subsequently "fix"
these usages properly. This is just a small step to be able to remove
the mutable properties from `TracerSettings`

## Test coverage

Just a refactoring, covered by existing tests.

## 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

… 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

… 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 👈