fix(sinks): separate Datadog validation from runtime construction

[kurochan]

Summary

Separate Datadog sink configuration validation from runtime construction.

In restricted environments such as CI, containers, and AI coding-agent sandboxes,
vector validate --no-environment is expected to validate structural configuration
without opening outbound connections or initializing runtime resources such as native
TLS trust stores.

Previously, Datadog sink validation could reach runtime client/TLS construction even
when no outbound request was made. In restricted sandbox environments, the macOS
Keychain may be unavailable; attempting to load native root certificates through it
caused validation to panic.

This PR makes the boundary explicit:

• Move configuration-only validation for the Datadog logs, metrics, events, and
  traces sinks into ValidatedSink::validate.
• Keep client, proxy, TLS, global Datadog option, and effective endpoint construction
  in the runtime build path.
• Move the APM stats flusher from a build-time detached task into the
  TracesSink::run lifecycle.
  • Request a final flush after both successful and failed trace drivers.
  • Bound shutdown acknowledgement waiting to 10 seconds so a stuck endpoint cannot
    delay shutdown indefinitely.
• Avoid unnecessary native certificate-store initialization when certificate
  verification is disabled.
• Consolidate shared Datadog endpoint, TLS, and client construction logic to reduce
  sink-specific validation/build drift.

Regular vector validate continues to build all sinks and remains the validation
mode for errors that require effective runtime construction. --no-environment
intentionally does not guarantee detection of every runtime construction error.

The APM flusher acknowledgement confirms that the final flush was attempted; it does
not guarantee that Datadog accepted the payload.

References

N/A

Vector configuration

No new user configuration was added. Unit tests cover the Datadog logs, metrics,
events, and traces sinks with their existing inline configurations and custom
endpoints.

How did you test this PR?

• cargo test -p vector --lib datadog
• cargo test -p vector-core tls::settings::test
• cargo test -p vector --lib sinks::datadog::traces::sink::tests
• cargo check -p vector --lib
• make check-clippy
• cargo fmt --all -- --check
• make check-changelog-fragments

Is this a breaking change?

• Yes
• No

Does this PR include user facing changes?

• Yes. A changelog fragment will be added in a follow-up commit after the PR number is assigned.
• No. A maintainer will apply the no-changelog label to this PR.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 78bf4f2fb0

ℹ️ 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".

[chatgpt-codex-connector]

Validate explicit sites when no endpoint is set

When endpoint is absent but site is explicitly malformed (for example, site = "bad site"), this helper returns Ok(()) without constructing the site-derived URL. The logs, metrics, and traces validators now rely on this helper, whereas their previous implementations parsed the URL derived from the configured site, so vector validate --no-environment now accepts a structurally unusable local configuration and defers the error until runtime construction. Validate a locally supplied site's derived base URL while continuing to defer values that come only from global runtime options.

Useful? React with 👍 / 👎.

[kurochan]

@codex fixed

[chatgpt-codex-connector]

To use Codex here, create an environment for this repo.