feat(otel): add OpenTelemetry SpanProcessor, Propagator, Extractor

[lcian]

Creates a new crate sentry-opentelemetry for integration with OTEL.

The implementation is based on a SpanProcessor that creates and finishes Sentry spans on OTEL span start/end.
There's also a Propagator/Extractor that injects the metadata (e.g. HTTP headers) required for distributed tracing to work.
It's based on our implementation for JS and other SDKs (https://develop.sentry.dev/sdk/telemetry/traces/opentelemetry/).

The goal with this initial version is:

• support OTEL <> Sentry span conversion and capturing
• capture OTEL span attributes
• link any messages/errors captured through the Sentry API to the correct spans, assuming that only the OTEL API is used to manage spans

Feedback appreciated on:

• SPAN_MAP, general Rust stuff, additions to performance API (@Swatinem)
• OTEL/SDKs things (@adinauer & @sl0thentr0py)

There are some todo items which will be addressed in follow-up PRs (not necessarily in this release).

[lcian]

Seems like Windows CI is getting stuck on test_captures_transaction for some reason. I'll stop it for now.

[adinauer]

Just gave this a quick glance and left some comments on what I noticed so far.

[lcian]

Just gave this a quick glance and left some comments on what I noticed so far.

Thank you!

[lcian]

Apparently we need to put each test in a different file or they will get stuck on Windows.

[Swatinem]

this looks reasonable to me.
Its a bit unfortunate how the lack of "onlyspans" means that you have to still deal with needing access to a TransactionOrSpan object instead of just being able to push finished spans with opaque parent ids into a global span sink.

[Swatinem]

lgtm

[Swatinem]

I still don’t understand why the otel sub-crate depends directly on release-health?

[lcian]

You're right it doesn't make much sense.

I was thinking there might be a scenario where someone depends on just sentry-core and sentry-opentelemetry, so I've added it to make sure that release-health is activated.
But actually users are always forced to depend on sentry as well in order to call sentry::init and effectively use the SDK, so they will choose whether to enable release-health when adding the sentry dependency itself.

I actually added this release-health flag to many of the subcrates when introducing this feature flag based on the above though process, see e.g. https://github.com/getsentry/sentry-rust/blob/master/sentry-tracing/Cargo.toml

On the other hand, if we don't do this and people upgrade the dependency without checking the release notes, they might end up without release-health and not know, which is not nice.
See for example https://github.com/rust-lang/crates.io/blob/main/Cargo.toml
if we remove release-health from the subcrates then the feature will be deactivated with a configuration like this.

Could you please advise on what you think is best here? @Swatinem