## Summary of changes

- Delete legacy `IConfigurationSource`
- Rename `ITelmeteredConfigurationSource` => `IConfigurationSource`
- Remove some "public" API workarounds
- Make some APIs `public` instead of `internal` (just to satisfy
compiler)
- Fix tests

## Reason for change

`ITelmeteredConfigurationSource` was introduced when
`IConfigurationSource` was public, and so could not be changed. We have
since removed that interface from the public API (it's not in
`Datadog.trace.Manual`) so now it simply adds confusion and complexity
(as it should _not_ be used internally in Datadog.Trace).

## Implementation details

This PR looks more complex than it is, because in order to replace all
the usages of the old `IConfigurationSource` with the new one, I had to
mark some other APIs public (and document them to satisfy the
analyzers).

It is mostly

- Delete legacy `IConfigurationSource`
- Rename `ITelmeteredConfigurationSource` => `IConfigurationSource`
- Fix any errors

I took the opportunity to also remove some of the `*Internal` methods
which were used to avoid calling the "public" APIs; seeing as these
aren't _actually_ public any more, that's just unnecessary duplication.

## Test coverage

The testing was a pain. The `ConfigurationBuilder` tests were all
designed to check that `ITelmeteredConfigurationSource` gave the same
results as `IConfigurationSource` (while never _explicitly_ specifying
what the "expected" behaviour was. I took some time to enumerate the
_actual_ expected values for the `NameValueCollection` source, but the
`Json` source has very different behaviour that is more of a pain to
test, so I chose to simplify a lot there. We could do a _lot_ to clean
up those tests, but I didn't want to add even more complexity in this
PR.

## Other details

To help "fix" the ASM tests I introduced a
`DictionaryObjectConfigurationSource`, in which you pass in a
`Dictionary<string, object>`. This is useful for testing (as it was
previously used) but is actually going to be useful for a future
clean-up PR too, so I kept it in Datadog.Trace instead of in the test
project.

Part of stack 
- #6370
- #6376
- #6385
- #6386 👈 This PR
- #6397
- #6399
- #6400
- #6405
- #6408

…nSource` (#6397)

Change how we "apply" settings from manual configuration to the
automatic side to use `IConfigurationSource`

## Reason for change

The previous design of how we "apply" settings made in code using manual
instrumentation required mutating a `TracerSettings` object after it was
already built. In fact, this is pretty much the _only_ place that we
mutate the settings.

By switching to using a "configuration source" approach, so that the
settings are built _once_ with the correct values opens up the option to
make these immutable (and therefore delete all of the `Immutable*`
settings we currently have. This reduces both code duplication and work
we do on startup, and opens the path to further refactoring
improvements.

Note that the public API does not change, so consumers of
Datadog.Trace.Manual are still working with a mutable object initially.

## Implementation details

Currently we pass a `Dictionary<string, object>` between the manual and
automatic side. Previously, we then iterated the keys, compared against
known values, and modified `TracerSettings` as required.

With the changes, we have a `ManualInstrumentationConfigurationSource`
which just "wraps" the `Dictionary<>`, and returns the correct value as
required for a given key. Overall, I think this is much cleaner.

Where things get messy is how we handle disabling specific integrations.
The existing dictionary is optimised for looping through the provided
values, fetching the setting that needs to be modified, and changing all
the required properties. Unfortunately, the `IConfigurationSource`
approach where we're looking up by a key like `DD_TRACE_NPGSQL_ENABLED`
works _horribly_ for this pattern 🙁. So I introduced an additional
approach which explicitly _additionally_ transfers the settings using
these values, making them just "standard" lookups.

> Note that due to backwards + forwards compatibility requirements
> - We _still_ need to send the "old" version of integration settings
from the manual side, in case it's used with an old version of the auto
instrumentation
> - We _still_ need to handle the "old" version of integration settings
in the auto side, in case it's used with an old version of the manual
instrumentation.
> - At least in this case we can use the more efficient
`IConfigurationSource` reader, so we don't pay the expense of retrieving
the settings. The only downside is a couple of extra allocations when
they _do_ disable integrations in code.


Minor other changes:
- Add helper ctor to `CompositeConfigurationSource` for creating the
internal list from a collection of `IConfigurationSource`
- Tweak `DictionaryObjectConfigurationSource` so we can derive from it
- Create a separate integration for <3.7.0 manual instrumentation that
uses the legacy settings, otherwise use the new settings objects

## Test coverage

Mostly covered by existing unit tests (and indirectly by integration
tests). Tweaked the test to test both the new and legacy configuration
source.

## Other details

Requires #6393 to fix how
we read integration settings


Part of stack 
- #6370
- #6376
- #6385
- #6386
- #6397 👈 This PR
- #6399
- #6400
- #6405
- #6408

…tead of mutating (#6399)

## Summary of changes

Change how CI Visibility creates its `TracerSettings` object to avoid
mutating settings afterwards

## Reason for change

This stack of changes is about removing duplication (among other things)
in the `TracerSettings` etc related objects. This is _partially_
required in order to remove the "snapshot generator" complexity that was
removed in #6370. Given
`TracerSettings` are not exposed publicly in Datadog.Trace, we want to
move to doing a "one shot" configuring of them, ultimately so that we
can make the object immutable (and remove `ImmutableTracerSettings` and
friends).

## Implementation details

CI Visibility is one of the few places where we mutate settings _after_
creating the `TracerSettings`. This is mostly because there's additional
logic that CI Visibility wants to perform.

Ultimately, the "solution" to that issue in this PR is to move that
logic into the `TracerSettings` constructor. I'm not entirely happy
about it, but it's the only approach I could find that works.

- Add a "dummy" configuration value to a configuration source when
creating the `TracerSettings`. This is used purely as a "switch" to say
"we're in CI Visibility mode".
- We absolutely could just pass this in as a constructor parameter. I
went that route first and then backed away, but can totally be swayed.
- Add an additional configuration source to update settings that we want
to change in CI Vis (e.g. logs injection).
- In the `TracerSettings` ctor, add an additional ignored URL when in CI
Vis mode, modify the default service name (if required) and add an
additional GlobalTag.

## Test coverage

I'd love to have some, but the CI Visibility configuration is kinda all
over the place, so if you have any pointers @tonyredondo I'm all ears...

## Other details

Part of stack 
- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399 👈 This PR
- #6400  
- #6405
- #6408

…utableDirectLogSubmissionSettings` (#6400)

## Summary of changes

Merge `DirectLogSubmissionSettings` with
`ImmutableDirectLogSubmissionSettings`

## Reason for change

There was never really a good reason for having these as separate types.
It was primarily to make testing a little easier and to mirror the
`TracerSettings`/`ImmutableTracerSettings` dichotomy, but as that's
going away, this is just unnecessary complexity

## Implementation details

- Moved the additional logic that was previously inside
`ImmutableDirectLogSubmissionSettings` into
`DirectLogSubmissionSettings`
- Renamed the `DirectLogSubmissionSettings` properties to match the
"Immutable" version (and remove the unnecessary prefix)
- Replace all usages of `Immutable*` with `DirectLogSubmissionSettings`
- Move `Immutable*Tests` into appropriate file and tweak
- Replace mutations with initialization (using `IConfigurationSource`)

## Test coverage

Essentially the same. I removed/tweaked some tests that are no longer
relevant

## Other details

Part of stack

- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399
- #6400  👈 This PR
- #6405
- #6408
- #6415

…tegrationSettings` (#6405)

## Summary of changes

Merge `IntegrationSettings` with `ImmutableIntegrationSettings`

## Reason for change

This stack of PRs is about doing one-shot configuration instead of
mutation. We never mutate these in the tracer after creation, so there's
no need for the separate types.

## Implementation details

- Moved additional logic (handling `DisabledNames` that was previously
inside `ImmutableIntegrationSettings` into `IntegrationSettings`
- Replace all usages of `Immutable*` with `IntegrationSettings`
- Move `Immutable*Tests` into appropriate file and tweak
- Replace mutations with initialization
- Reorder initialization of `DisabledIntegrationNames` in
`TracerSettings` so that it can be used in the `IntegrationSettings`
constructor

## Test coverage

All covered by existing details

## Other details

Part of Stack
- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399
- #6400
- #6405 👈 This PR
- #6408
- #6415

…ettings` (#6415)

## Summary of changes

Merge `TracerSettings` with `ImmutableTracerSettings`

## Reason for change

This stack of PRs is about doing one-shot configuration instead of
mutation. We never mutate these in the tracer after creation, so there's
no need for the separate types.

## Implementation details

- Make the properties in `TracerSettings` get-only. 
- Make the collections in `TracerSettings` readonly.
- Move logic that used to be in the constructor of
`ImmutableTracerSettings` into `TracerSettings`
- e.g. Service/Version/Env were being changed based on DD_TAGS values.
Moved that to TracerSettings and (importantly) added missing telemetry
recording of these values.
  - Added missing recording of _effective_ `DisabledInstegrations`
- Moving this logic caused some _tests_ to be broken (checking default
values). Updated the expected values of those tests in a single
- Replace all usages of `ImmutableTracerSettings` with `TracerSettings`
- Move `ITracer` to Datadog.Trace.Manual
- It's only used there, and references the manual-version of
`ImmutableTracerSettings` which we _want_ to keep.
- Move `Immutable*Tests` into appropriate file and tweak
- Replace mutations with initialization in tests

## Test coverage

All covered by existing tests (I hope) 🤞 

## Other details

There's still a _lot_ of scope to improve this 

Part of Stack
- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399
- #6400
- #6405
- #6408
- #6415 👈 This PR

## Summary of changes

- Delete legacy `IConfigurationSource`
- Rename `ITelmeteredConfigurationSource` => `IConfigurationSource`
- Remove some "public" API workarounds
- Make some APIs `public` instead of `internal` (just to satisfy
compiler)
- Fix tests

## Reason for change

`ITelmeteredConfigurationSource` was introduced when
`IConfigurationSource` was public, and so could not be changed. We have
since removed that interface from the public API (it's not in
`Datadog.trace.Manual`) so now it simply adds confusion and complexity
(as it should _not_ be used internally in Datadog.Trace).

## Implementation details

This PR looks more complex than it is, because in order to replace all
the usages of the old `IConfigurationSource` with the new one, I had to
mark some other APIs public (and document them to satisfy the
analyzers).

It is mostly

- Delete legacy `IConfigurationSource`
- Rename `ITelmeteredConfigurationSource` => `IConfigurationSource`
- Fix any errors

I took the opportunity to also remove some of the `*Internal` methods
which were used to avoid calling the "public" APIs; seeing as these
aren't _actually_ public any more, that's just unnecessary duplication.

## Test coverage

The testing was a pain. The `ConfigurationBuilder` tests were all
designed to check that `ITelmeteredConfigurationSource` gave the same
results as `IConfigurationSource` (while never _explicitly_ specifying
what the "expected" behaviour was. I took some time to enumerate the
_actual_ expected values for the `NameValueCollection` source, but the
`Json` source has very different behaviour that is more of a pain to
test, so I chose to simplify a lot there. We could do a _lot_ to clean
up those tests, but I didn't want to add even more complexity in this
PR.

## Other details

To help "fix" the ASM tests I introduced a
`DictionaryObjectConfigurationSource`, in which you pass in a
`Dictionary<string, object>`. This is useful for testing (as it was
previously used) but is actually going to be useful for a future
clean-up PR too, so I kept it in Datadog.Trace instead of in the test
project.

Part of stack 
- #6370
- #6376
- #6385
- #6386 👈 This PR
- #6397
- #6399
- #6400
- #6405
- #6408

…nSource` (#6397)

Change how we "apply" settings from manual configuration to the
automatic side to use `IConfigurationSource`

## Reason for change

The previous design of how we "apply" settings made in code using manual
instrumentation required mutating a `TracerSettings` object after it was
already built. In fact, this is pretty much the _only_ place that we
mutate the settings.

By switching to using a "configuration source" approach, so that the
settings are built _once_ with the correct values opens up the option to
make these immutable (and therefore delete all of the `Immutable*`
settings we currently have. This reduces both code duplication and work
we do on startup, and opens the path to further refactoring
improvements.

Note that the public API does not change, so consumers of
Datadog.Trace.Manual are still working with a mutable object initially.

## Implementation details

Currently we pass a `Dictionary<string, object>` between the manual and
automatic side. Previously, we then iterated the keys, compared against
known values, and modified `TracerSettings` as required.

With the changes, we have a `ManualInstrumentationConfigurationSource`
which just "wraps" the `Dictionary<>`, and returns the correct value as
required for a given key. Overall, I think this is much cleaner.

Where things get messy is how we handle disabling specific integrations.
The existing dictionary is optimised for looping through the provided
values, fetching the setting that needs to be modified, and changing all
the required properties. Unfortunately, the `IConfigurationSource`
approach where we're looking up by a key like `DD_TRACE_NPGSQL_ENABLED`
works _horribly_ for this pattern 🙁. So I introduced an additional
approach which explicitly _additionally_ transfers the settings using
these values, making them just "standard" lookups.

> Note that due to backwards + forwards compatibility requirements
> - We _still_ need to send the "old" version of integration settings
from the manual side, in case it's used with an old version of the auto
instrumentation
> - We _still_ need to handle the "old" version of integration settings
in the auto side, in case it's used with an old version of the manual
instrumentation.
> - At least in this case we can use the more efficient
`IConfigurationSource` reader, so we don't pay the expense of retrieving
the settings. The only downside is a couple of extra allocations when
they _do_ disable integrations in code.


Minor other changes:
- Add helper ctor to `CompositeConfigurationSource` for creating the
internal list from a collection of `IConfigurationSource`
- Tweak `DictionaryObjectConfigurationSource` so we can derive from it
- Create a separate integration for <3.7.0 manual instrumentation that
uses the legacy settings, otherwise use the new settings objects

## Test coverage

Mostly covered by existing unit tests (and indirectly by integration
tests). Tweaked the test to test both the new and legacy configuration
source.

## Other details

Requires #6393 to fix how
we read integration settings


Part of stack 
- #6370
- #6376
- #6385
- #6386
- #6397 👈 This PR
- #6399
- #6400
- #6405
- #6408

…tead of mutating (#6399)

## Summary of changes

Change how CI Visibility creates its `TracerSettings` object to avoid
mutating settings afterwards

## Reason for change

This stack of changes is about removing duplication (among other things)
in the `TracerSettings` etc related objects. This is _partially_
required in order to remove the "snapshot generator" complexity that was
removed in #6370. Given
`TracerSettings` are not exposed publicly in Datadog.Trace, we want to
move to doing a "one shot" configuring of them, ultimately so that we
can make the object immutable (and remove `ImmutableTracerSettings` and
friends).

## Implementation details

CI Visibility is one of the few places where we mutate settings _after_
creating the `TracerSettings`. This is mostly because there's additional
logic that CI Visibility wants to perform.

Ultimately, the "solution" to that issue in this PR is to move that
logic into the `TracerSettings` constructor. I'm not entirely happy
about it, but it's the only approach I could find that works.

- Add a "dummy" configuration value to a configuration source when
creating the `TracerSettings`. This is used purely as a "switch" to say
"we're in CI Visibility mode".
- We absolutely could just pass this in as a constructor parameter. I
went that route first and then backed away, but can totally be swayed.
- Add an additional configuration source to update settings that we want
to change in CI Vis (e.g. logs injection).
- In the `TracerSettings` ctor, add an additional ignored URL when in CI
Vis mode, modify the default service name (if required) and add an
additional GlobalTag.

## Test coverage

I'd love to have some, but the CI Visibility configuration is kinda all
over the place, so if you have any pointers @tonyredondo I'm all ears...

## Other details

Part of stack 
- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399 👈 This PR
- #6400  
- #6405
- #6408

…utableDirectLogSubmissionSettings` (#6400)

## Summary of changes

Merge `DirectLogSubmissionSettings` with
`ImmutableDirectLogSubmissionSettings`

## Reason for change

There was never really a good reason for having these as separate types.
It was primarily to make testing a little easier and to mirror the
`TracerSettings`/`ImmutableTracerSettings` dichotomy, but as that's
going away, this is just unnecessary complexity

## Implementation details

- Moved the additional logic that was previously inside
`ImmutableDirectLogSubmissionSettings` into
`DirectLogSubmissionSettings`
- Renamed the `DirectLogSubmissionSettings` properties to match the
"Immutable" version (and remove the unnecessary prefix)
- Replace all usages of `Immutable*` with `DirectLogSubmissionSettings`
- Move `Immutable*Tests` into appropriate file and tweak
- Replace mutations with initialization (using `IConfigurationSource`)

## Test coverage

Essentially the same. I removed/tweaked some tests that are no longer
relevant

## Other details

Part of stack

- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399
- #6400  👈 This PR
- #6405
- #6408
- #6415

…tegrationSettings` (#6405)

## Summary of changes

Merge `IntegrationSettings` with `ImmutableIntegrationSettings`

## Reason for change

This stack of PRs is about doing one-shot configuration instead of
mutation. We never mutate these in the tracer after creation, so there's
no need for the separate types.

## Implementation details

- Moved additional logic (handling `DisabledNames` that was previously
inside `ImmutableIntegrationSettings` into `IntegrationSettings`
- Replace all usages of `Immutable*` with `IntegrationSettings`
- Move `Immutable*Tests` into appropriate file and tweak
- Replace mutations with initialization
- Reorder initialization of `DisabledIntegrationNames` in
`TracerSettings` so that it can be used in the `IntegrationSettings`
constructor

## Test coverage

All covered by existing details

## Other details

Part of Stack
- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399
- #6400
- #6405 👈 This PR
- #6408
- #6415

…terSettings` (#6408)

## Summary of changes

Merge `ExporterSettings` with `ImmutableExporterSettings`

## Reason for change

This stack of PRs is about doing one-shot configuration instead of
mutation. We never mutate these in the tracer after creation, so there's
no need for the separate types.

## Implementation details

- Made the properties in `ExporterSettings` get-only. This required
quite a lot of work because we were doing a lot of mutating of the
settings in the "helper" functions.
- I only _lightly_ refactored those methods (as much as possible) to
avoid setting the properties in the functions and instead returning the
details to set later.
- These are prime candidates for some _much_ heavier refactoring later,
but I didn't want to get bogged down with that in this PR
- Replace all usages of `Immutable*` with `ExporterSettings`
- Replace usages of `AgentUriInternal` with `AgentUri`
- Move `Immutable*Tests` into appropriate file and tweak
- Replace mutations with initialization

## Test coverage

All covered by existing details

## Other details

Part of Stack
- #6370
- #6376
- #6385
- #6386
- #6397 
- #6399
- #6400
- #6405
- #6408 👈 This PR
- #6415

…ettings` (#6415)

Merge `TracerSettings` with `ImmutableTracerSettings`

This stack of PRs is about doing one-shot configuration instead of
mutation. We never mutate these in the tracer after creation, so there's
no need for the separate types.

- Make the properties in `TracerSettings` get-only.
- Make the collections in `TracerSettings` readonly.
- Move logic that used to be in the constructor of
`ImmutableTracerSettings` into `TracerSettings`
- e.g. Service/Version/Env were being changed based on DD_TAGS values.
Moved that to TracerSettings and (importantly) added missing telemetry
recording of these values.
  - Added missing recording of _effective_ `DisabledInstegrations`
- Moving this logic caused some _tests_ to be broken (checking default
values). Updated the expected values of those tests in a single
- Replace all usages of `ImmutableTracerSettings` with `TracerSettings`
- Move `ITracer` to Datadog.Trace.Manual
- It's only used there, and references the manual-version of
`ImmutableTracerSettings` which we _want_ to keep.
- Move `Immutable*Tests` into appropriate file and tweak
- Replace mutations with initialization in tests

All covered by existing tests (I hope) 🤞

There's still a _lot_ of scope to improve this

Part of Stack
- #6370
- #6376
- #6385
- #6386
- #6397
- #6399
- #6400
- #6405
- #6408
- #6415 👈 This PR