Add OpenTelemetry tracing support for Stripe API calls

[lmcrean]

Problem

Users cannot trace Stripe API calls through their observability systems without manually wrapping every API call. The SDK formats URLs like /v1/charges/ch_123 but OpenTelemetry requires URL templates like /v1/charges/{id} to prevent cardinality explosion in metrics.

Issue #2104 requested built-in OpenTelemetry integration with proper url.template semantic convention support.

Solution

Add opt-in OpenTelemetry instrumentation that automatically creates spans for all Stripe HTTP operations. URL templates are tracked separately from formatted paths and propagated via context to comply with OpenTelemetry semantic conventions v1.24.

Users enable tracing with one line:

stripe.SetTracerProvider(otel.GetTracerProvider())

All subsequent API calls automatically create spans with proper attributes (http.method, http.status_code, url.template, stripe.request_id, etc.).

Changes

New files:

• otel.go - OpenTelemetry instrumentation (134 lines)
• otel_test.go - Test coverage (203 lines, 9 test functions)

Modified files:

• params.go - Added URLTemplate field for template tracking
• stripe.go - Instrumented Do(), DoStreaming(), CallRaw(), CallStreaming() + added FormatURLPathWithTemplate() helper
• example_test.go - Added ExampleSetTracerProvider() and ExampleFormatURLPathWithTemplate()
• go.mod/go.sum - Added OpenTelemetry dependencies (v1.24.0)

Testing

go build .  # Build succeeds
go test ./... -run TestSetTracerProvider  # Tests pass (requires stripe-mock for integration tests)

Tests cover TracerProvider configuration, span creation with attributes, context propagation, error handling, streaming operations, and URL template formatting.

Breaking Changes

None. Implementation is opt-in; backward compatible and non-intrusive.

Closes #2104

[mbroshi-stripe]

@lmcrean Thanks for this PR! 🙏 High-level, your approach looks great, but I haven't had a chance to give a careful read-through yet. I'll get to that later this week

[mbroshi-stripe]

Thanks again for picking this up! I think we need to think through the design a little more carefully before we can merge a change like this. I'll move the discussion over to the parent issue.

[mbroshi-stripe]

Won't this overwrite the existing context.Context?

[mbroshi-stripe]

@lmcrean Would you mind fleshing out your design more carefully in the parent issue? One question I have is why you decided to use stripe.SetTracerProvider as a global configuration instead of configuring it per-client, or instead of calling something like tp := otel.GetTracerProvider() inside the SDK. I'd like to see some of your design choices, their pros/cons, and how they compare to what's used in other libraries. Again, I appreciate your submission, but I feel this will require more careful design work before we merge in a PR.