feat(trace_buffer): adopt libdatadog's TraceBuffer & borrow the host tokio runtime

[Aaalibaba42]

What?

Replace the in-tree AsyncTraceExporter (buffering, flushing, shutdown
orchestration) with libdatadog's TraceBuffer + SharedRuntime, the same
implementation that was upstreamed from this repo. The DatadogExporter is now
a thin wrapper that owns a TraceBuffer and a SharedRuntime instead of
managing its own background thread, batch queue, and condvar synchronisation.

When the exporter is constructed from inside a tokio runtime — the common case
for an async application booting up dd-trace-rs from its #[tokio::main] — the
underlying SharedRuntime now borrows the host runtime instead of spawning
a second one. Borrowed mode is what makes Drop and shutdown work cleanly
from a host worker thread without nested-runtime panics.

Why?

• The trace buffer logic was moved to libdatadog so it can be shared across
  language tracers. Keeping a duplicate copy here means diverging bug fixes,
  duplicated tests, and extra maintenance. Adopting the libdatadog version
  lets us delete ~860 lines of exporter/mod.rs and benefit from upstream
  improvements (e.g. runtime-aware shutdown) for free.
• The previous in-tree exporter, and naïve adoption of the libdatadog one,
  both panicked with Cannot start a runtime from within a runtime when the
  user owned a tokio runtime — which is the only sane way to run a modern
  Rust web service. Borrowed-mode SharedRuntime is the proper fix.

How?

1. Adopt TraceBuffer + SharedRuntime

• Deleted datadog-opentelemetry/src/exporter/mod.rs entirely.
• Rewired DatadogExporter in span_exporter.rs to construct a
  TraceExporter via TraceExporterBuilder and wrap it in a TraceBuffer.
  MapperExporter implements Export<SpanData> for the OTel→DD conversion
  and lives alongside the new DatadogExporter.

2. Pick the right runtime backing at construction time

let runtime = match tokio::runtime::Handle::try_current() {
    Ok(handle) => Arc::new(SharedRuntime::from_handle(handle)),
    Err(_)     => Arc::new(SharedRuntime::new()?),
};

If we are constructed from inside a tokio runtime, borrow it; otherwise spin
up our own. Borrowed mode gives up fork-safety in exchange for letting
Drop/shutdown work without block_on — see the borrowed-runtime work in
libdd-shared-runtime.

3. Drive the async builder from a sync constructor

DatadogExporter::new is sync (-> Self) but the new
TraceExporterBuilder::build_async is async. Calling
SharedRuntime::block_on in borrowed mode returns
Unsupported; calling tokio::runtime::Handle::block_on from a tokio worker
panics. Solution: a small poll_to_completion helper — a hand-rolled,
thread-park-based executor — that drives build_async to completion. This is
safe because build_async's only suspension point is a single non-blocking
mpsc send into a freshly-created telemetry-worker channel, which is always
Ready on first poll. The contract is documented at the helper's call site.

4. Non-blocking shutdown

DatadogExporter::shutdown now uses
SharedRuntime::trigger_shutdown_signal + wait_shutdown_done (Condvar-based,
no block_on). To avoid deadlocking the single worker thread of a
current_thread host runtime, the wait is conditional on the host runtime's
flavor:

• Multi-threaded host — tokio::task::block_in_place around
  wait_shutdown_done so other workers can keep driving the shutdown tasks.
• current_thread host — fire-and-forget trigger_shutdown_signal and
  skip the Condvar wait entirely; blocking the only worker thread would
  prevent the shutdown tasks from ever running. This is best-effort; an
  async-aware shutdown_async API is the long-term fix.

A small tokio_is_multi_thread() helper does the flavor detection.

5. Drop for DatadogExporter

Callers that forget to call shutdown() now get a best-effort teardown with a
1s timeout. The impl is idempotent: a prior explicit shutdown makes the
Drop a no-op. Regression tests exercise drop-inside-tokio and
drop-after-explicit-shutdown, both asserting the borrowed-runtime path
(exporter.runtime.is_borrowed()).

Tests

• Re-enabled (and rewrote) test_drop_inside_tokio_runtime and
  test_drop_after_explicit_shutdown_is_noop, which used to be #[ignore]d
  while the tokio-in-tokio panic was open. Both now run under
  #[tokio::test(flavor = "multi_thread", worker_threads = 2)] and assert
  exporter.runtime.is_borrowed().
• Added test_new_outside_tokio_picks_owned_runtime for the owned-runtime
  fallback.
• Existing snapshot and integration tests pass; flaky test agent /
  global-state tests are unchanged.

Additional notes

• libdatadog deps in Cargo.toml currently point to the
  jwiriath/tracebuffer-sharedruntime-rusttracer branch via path deps for
  local development; the workspace comment documents that these need to flip
  back to git refs (or pinned versions) once the libdatadog PR lands and is
  published.
• The test-utils feature gate exposes a wait_ready hook on
  MapperExporter so snapshot tests can wait for agent info before asserting
  on stats-derived metrics.
• No change to the public DatadogExporter API surface: send_chunk,
  force_flush, shutdown, and queue_metrics all keep their existing
  signatures.

[paullegranddc]

Overall, the way this currently works , inheriting the runtime and trying to perform a shutdown in the caller tokio context seems dodgy.

I think it would be cleaner and less brittle if we

1. always created a new runtime (possibly a current thread one)
2. sent it in a separate thread
3. create the trace exporter and spawn tasks in the new thread
4. wait on a shutdown signal, where we shutdown the shared runtime and drop it.

[paullegranddc]

Just a reminder that this shouldn't be merged

[paullegranddc]

Why have the snapshot test changed?

[paullegranddc]

DIscussed IRL but I would prefer if we always created a new runtime for the SharedRuntime, and sent it in a brand new thread, not risking interacting with it from the customer side

[paullegranddc]

This seems like a very brittle expectations

[paullegranddc]

So if the runtime is not multi threaded we just block?
This is not correct as the shutdown is an async operation, so if the shared runtime inherited the same current thread runtime as the app, we will block it and the trace buffer flush won't be able to make progress

[paullegranddc]

Also shutting down the trace buffer should already be flushing lefotver spans in the pipe. No need to flush and wait here

[paullegranddc]

I'd prefer if we used https://docs.rs/futures/latest/futures/executor/fn.block_on.html which does the same

[mabdinur]

Hey @Aaalibaba42,

Hope you’re doing well! I have a PR that’s currently blocked on this change, so I wanted to check in and see if you have a rough ETA for when this might be merged.

No rush if you’re still working through it, just trying to plan around the dependency 😄

[Aaalibaba42]

Hey @mabdinur, this might still be a few days. The changes here lead to discussions and changes in libdatadog that must be settled before this is merged, I'm hoping to have this merged before the end of next week but it's the last PR of the effort :/.