test(cpp): enable otel tracestate sampling

[MilanGarnier]

Enables C++ OpenTelemetry tracestate sampling coverage. Stacked on #7518.

[github-actions]

CODEOWNERS have been resolved as:

manifests/cpp.yml                                                       @DataDog/system-tests-reviewers

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0378ec0860

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[datadog-prod-us1-3]

✅ All CI checks and tests passed.

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

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

[dougqh]

🤖 Comment from Claude (via Claude Code), reviewing this PR at a user's request.

I think test_precision_boundary_decisions in tests/parametric/test_otel_tracestate_sampling.py has incorrect hardcoded expected values for both parametrized cases.

I reimplemented the sampling formula documented in tests/test_otel_tracestate_sampling.py's module docstring:

h = (trace_id * 1111111111111111111) mod 2**64
rv = (~h & (2**64-1)) >> 8
th = round((1 - rate) * 2**56)
sampled = rv >= th

and verified it reproduces the existing, already-verified SAMPLING_RATE_0_1 fixtures exactly (rv matches to the hex digit, and the sampled/dropped decision derived from rv >= th matches too, for trace IDs 1, 10, 100, 1000, 83).

Applying that same validated formula to the two new boundary vectors:

• rate-0.1-kept (trace_id 0x03A93EE8B1999F00): I get rv = e6666666666666, sampled = False — but the test asserts rv = e6666666666668 (equal to th) and expected_sampled = True.
• rate-0.05-dropped (trace_id 5401449561355763072): I get rv = f3333333333331, sampled = True — but the test asserts rv = f333333333332f and expected_sampled = False.

In both cases the rv value and the sampled/dropped direction come out flipped relative to what the test expects. This should fail against a tracer that implements the algorithm correctly (or could mask a bug in one that doesn't). Might be worth regenerating these two vectors — unlike the pre-existing SAMPLING_RATE_* tables, these weren't cross-checked against the verified sampling_rates.csv.

[MilanGarnier]

Applying that same validated formula to the two new boundary vectors:

• rate-0.1-kept (trace_id 0x03A93EE8B1999F00): I get rv = e6666666666666, sampled = False — but the test asserts rv = e6666666666668 (equal to th) and expected_sampled = True.
• rate-0.05-dropped (trace_id 5401449561355763072): I get rv = f3333333333331, sampled = True — but the test asserts rv = f333333333332f and expected_sampled = False.

In both cases the rv value and the sampled/dropped direction come out flipped relative to what the test expects. This should fail against a tracer that implements the algorithm correctly (or could mask a bug in one that doesn't). Might be worth regenerating these two vectors — unlike the pre-existing SAMPLING_RATE_* tables, these weren't cross-checked against the verified sampling_rates.csv.

@dougqh This is intentional. In these edge cases the imprecision comes initially from computing th, so rv is set to a value explicitly agreeing the sampling decision made internally using dd sampling.