Fix data_streams settings registration to avoid load-order dependency

[ericfirth]

What does this PR do?
Moves the data_streams settings block (enabled, interval) directly into Core::Configuration::Settings's class body in settings.rb, the same way profiling/crashtracking/other product settings are registered.
Removes lib/datadog/data_streams/configuration.rb and lib/datadog/data_streams/extensions.rb, which registered data_streams settings via Core::Configuration::Settings.extend(...), only triggered when lib/datadog/data_streams.rb was required.

Motivation:
settings.data_streams previously only existed if lib/datadog/data_streams.rb was required, which only happens via the full lib/datadog.rb entrypoint.
Any process with a narrower require chain (e.g. some CI test suites that require individual products directly) hit NoMethodError: undefined method 'data_streams', silently caught and logged as a warning by Components#build_data_streams.
Registering the settings inline removes the load-order dependency entirely, matching the more robust pattern already used elsewhere in the codebase.

Change log entry
None. This is an internal fix for an edge case affecting narrow-require processes/tests; settings.data_streams already worked correctly in the normal boot path and no defaults, option names, or public behavior changed.

Additional Notes:
None.

How to test the change?
Added describe "#data_streams" coverage in spec/datadog/core/configuration/settings_spec.rb for enabled/enabled=/interval/interval=, matching the existing #crashtracking tests.
Verified via a local repro (using the narrow require chain from spec/datadog/di/integration/implicit_enablement_spec.rb) that settings.data_streams raised NoMethodError on master and no longer does with this change.

[datadog-prod-us1-3]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 90.25% (-0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3089b0d | Docs | View more details | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-08-20 13:50:06

Comparing candidate commit 3089b0d in PR branch eric.firth/fix-data-streams-settings-load-order with baseline commit 7a21844 in branch master.

📊 Benchmarking dashboard

Found 0 performance improvements and 0 performance regressions! Performance is the same for 48 metrics, 1 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 ----------------------------------'

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:tracing - Tracing.continue_trace!

• unstable throughput [-1662.456op/s; +2252.232op/s] or [-4.263%; +5.776%]

[eregon]

Nice, much simpler and more reliable

[ivoanjo]

👍 LGTM this is great!

This pattern of "extending settings instead of inlining" is something that other components of dd-trace-rb tried and I think overall the experiment didn't go very well.

It causes order-dependent failures, it's really confusing (where is this defined?), and in the end is not particularly "modular" -- monkey patching means the original classes are modified anyway.

So I'm a big fan to going back to basics. Maybe one day we'll come up with a new way of doing settings and we'll be able to separate these out again, but for now I think this is the way to go.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 003d1989d4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[p-datadog]

Sorry, if a test misrequires a product (data streams in this case, per PR description), I don't find this a valid reason to move product functionality into core.

What is the test fix? ~5 lines of requires added?

[vpellan]

I don't have a strong opinion about it but if we really want to keep core and data_stream separated, we could instead extend Datadog::DataStreams::Configuration::Settings at the end of the class like we do for tracing and opentelemetry. It would end with the same result but still in their own product folder in the codebase

[ivoanjo]

we could instead extend Datadog::DataStreams::Configuration::Settings at the end of the class like we do for tracing and opentelemetry.

As I mentioned above, I think extension here is a mistake -- monkey patching is confusing and creates these sharp edges.

(I think tracing and opentelemetry should move away from this pattern as well)

Yes, we should have a better solution for configuring modules independently, and I would 100% support that as an alternative here, but IMHO that should not be "monkey patching into core".

[ivoanjo]

For further evidence of why I claim our "monkey patch" approach doesn't make sense, look at #6291 :

We have open_feature/configuration.rb which makes it look like there's separation, but then supported-configurations.json/supported_configurations.rb are global, inside of core, and also need to change!

Our current setup "pretends" like configuration is local, but it's not really -- it needs global changes, hence my claim that we should start pretending to be local until we actually make it local (and in such a situation, adding a new setting would mean core actually wouldn't need to change, including for env vars).