refactor: introduce ConfigProvider for unified env-var resolution

[bm1549]

Description

Introduces ConfigProvider, a source-list resolver that walks ordered ConfigSource implementations to resolve DD_* configuration values with telemetry origin attribution. This is a pure refactor — every existing test passes unchanged. The point is to lay an extensible foundation: PR follow-ups (notably the stable-configuration work that originally tried to plumb fleet/local YAML sources per call site) can add new sources by implementing ConfigSource once, and every consumer that goes through ConfigProvider automatically participates in the precedence chain.

Architecture

Type	Role
ConfigSource (interface)	One origin of DD_* values. Returns Optional<std::string> for a key plus a ConfigMetadata::Origin and optional config_id.
EnvironmentSource	Concrete source backed by std::getenv.
ConfigProvider	Owns up to three sources (fleet, env, local) plus a metadata sink. Templated resolve<T> walks the source list in precedence order, records each non-empty source into the metadata vector, returns the highest-precedence value.

Precedence: fleet_stable > env > user/code > local_stable > default. PR R registers only EnvironmentSource (fleet and local source pointers are nullptr and skipped); a follow-up PR will register FleetStableConfigSource and LocalStableConfigSource, at which point every existing provider.get_*(...) call site automatically gains stable-config support.

Accessors

Each accessor parses the source's raw string into the target type and writes telemetry origin into the metadata map:

• get_string(name, env_key, user_value, default_value)
• get_bool(name, env_key, user_value, default_value) — matches existing env-var convention (any non-falsy string is true)
• get_uint64(name, env_key, user_value, default_value, logger) — logs and falls through on parse failure
• get_double(name, env_key, user_value, default_value, logger) — same
• get_tags(name, env_key, user_value, default_value, logger) — parses comma-separated key:value pairs
• get_propagation_styles(name, env_key, user_value, default_value, logger) — parses style-name lists

Internally each accessor reuses a generic resolve<T> template that takes a ParseFn and a StringifyFn. Adding a new typed accessor is one method + one parse/stringify pair.

Migrations

Out of 17 call sites of resolve_and_record_config on main, 12 migrate cleanly to ConfigProvider:

File	Sites migrated	Sites kept on resolve_and_record_config
trace_sampler_config.cpp	2 (sample_rate, max_per_second)	0
tracer_config.cpp	10 (service, tags, baggage limits, all bool flags)	4 (DD_ENV, DD_VERSION, extraction_styles, injection_styles)
span_sampler_config.cpp	0	1 (sampling rules)

The 5 sites that stay use semantics the provider does not yet model:

• DD_ENV / DD_VERSION — record no DEFAULT metadata entry when unset (the provider always records one).
• DD_TRACE_PROPAGATION_STYLE_{EXTRACT,INJECT} — fall back across a specific → legacy → global env-key chain, which the env_config loader resolves before resolve_and_record_config sees a single value.
• DD_SPAN_SAMPLING_RULES — operates on a pre-parsed Optional<vector<Rule>> rather than a string. The rule-parsing JSON validator is non-trivial and lives in load_span_sampler_env_config.

These can be migrated in follow-ups once ConfigProvider gains a "no-default" mode and a sampling-rules accessor. The 3-arg resolve_and_record_config overload stays in include/datadog/config.h for now.

Other changes

• ConfigMetadata grows two new Origin enum values (LOCAL_STABLE_CONFIG, FLEET_STABLE_CONFIG) and an optional config_id field. No production code uses them yet. They exist so ConfigProvider's telemetry recording is well-typed when a follow-up adds the stable sources.
• parse_propagation_styles moves from tracer_config.cpp's anonymous namespace to the public propagation_style.h so ConfigProvider::get_propagation_styles can reuse it.
• telemetry_impl.cpp's origin-serialization switch handles the new enum values (emits local_stable_config / fleet_stable_config and forwards config_id for the fleet case).
• env_config loaders still parse the keys the provider also reads. This preserves the existing parse-failure-as-Error behavior (the provider's "log and fall through" semantics are reached only in success cases).

Files

File	Change
src/datadog/config_source.h	New — interface
src/datadog/environment_source.{h,cpp}	New — std::getenv source
src/datadog/config_provider.{h,cpp}	New — source-list resolver
include/datadog/config.h	Extends ConfigMetadata::Origin; adds config_id field
include/datadog/propagation_style.h	Adds parse_propagation_styles declaration
src/datadog/propagation_style.cpp	Adds parse_propagation_styles implementation
src/datadog/telemetry/telemetry_impl.cpp	Handle the two new origin values
src/datadog/trace_sampler_config.cpp	Migrate 2 sites
src/datadog/tracer_config.cpp	Migrate 10 sites; drop the duplicate parse_propagation_styles
BUILD.bazel, CMakeLists.txt, test/CMakeLists.txt	Wire the new files
test/test_config_provider.cpp	New — 19 unit tests covering the source interface, env source, and every accessor

Testing

• 199,545 assertions across 126 test cases pass — every pre-existing test passes unchanged.
• 19 new [config_provider] tests cover: MapSource fixture, EnvironmentSource (present / missing / empty), get_string (env-wins / user-wins-over-default / env-beats-user / default-only / null-source-pointers-skipped / full-precedence-chain), get_bool (true / false), get_uint64 (valid / invalid-falls-through), get_double, get_tags (valid / malformed), get_propagation_styles (valid / invalid-falls-through).

Motivation

Lays the source-list-resolver foundation so a follow-up PR can add universal stable-configuration support. Once FleetStableConfigSource and LocalStableConfigSource are added to ConfigProvider's source list, every DD_* config key resolved through the provider automatically participates in fleet_stable > env > user/code > local_stable > default precedence, without per-call-site wiring.

Additional Notes

Jira ticket: [PROJ-IDENT]

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-05-15 02:09:32

Comparing candidate commit dafd944 in PR branch bm1549/config-provider with baseline commit 34520f2 in branch main.

Found 1 performance improvements and 0 performance regressions! Performance is the same for 0 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:BM_TraceTinyCCSource

• 🟩 execution_time [-3.266ms; -2.825ms] or [-4.137%; -3.578%]

[datadog-datadog-prod-us1]

🎯 Code Coverage (details)
• Patch Coverage: 93.66%
• Overall Coverage: 90.78% (-0.07%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: dafd944 | Docs | Datadog PR Page | Give us feedback!}