Feature Request: add OpenTelemetry tracing backend

[timvaillancourt]

Feature Description

Vitess currently supports two tracing backends: opentracing-jaeger and opentracing-datadog. Both are built on the OpenTracing API, which has been superseded by OpenTelemetry

The jaeger-client-go library we depend on has been archived for a while now and the Jaeger project themselves recommend migrating to OpenTelemetry. Our Datadog plugin uses the OpenTracing bridge in dd-trace-go, which is also the old way of doing things

OpenTelemetry has become the industry standard for observability. Pretty much every tracing backend worth using supports OTLP natively now: Jaeger (v1.35+), Grafana Tempo, Datadog Agent, Honeycomb, etc. A single OTLP exporter replaces our need for vendor-specific client libraries

Why this matters

1. Dead dependencies — jaeger-client-go is archived. No security patches, no bug fixes. We're shipping a dependency the upstream maintainers have abandoned
2. Dependency weight — dd-trace-go.v1 pulls in a heavy transitive dependency tree. Removing it in favour of the OTel SDK would trim go.mod significantly
3. Vendor neutrality — with OTLP, users point --otel-endpoint at whatever backend they use. No more needing a Vitess-side plugin per vendor
4. Industry direction — OpenTracing is done. OpenTelemetry is the CNCF standard. We should be on it

Proposed approach

The existing tracingService interface in go/trace/ is a clean abstraction layer — 348+ call sites use trace.NewSpan/trace.Span without knowing the backend. This means adding OTel is well-contained:

1. Add a new --tracer opentelemetry backend using the OTel SDK + OTLP/gRPC exporter
2. Deprecate opentracing-jaeger and opentracing-datadog for one release cycle (log a warning at startup)
3. Remove the old backends in the following release, along with their dependencies

Use Case(s)

Any Vitess user that wants distributed tracing. Today they're forced to use archived/legacy client libraries. This gives them a modern, vendor-neutral option