This is another attempt at fixing #7386. Previous PR was #7379. The difference is, this time it works! In the following screenshot, handle_input is a currently active span.

I had to make some patches to Sentry, most notably:

• feat(sentry-tracing): add span fields to breadcrumbs getsentry/sentry-rust#708
• fix: delay sampling of tracing spans to finish getsentry/sentry-rust#712

The way we configure Sentry is quite tricky:

First and foremost, we need to understand that the tracing adapter for Sentry has a span_filter configuration. When a span gets filtered out there, the rest of sentry-tracing never sees the data in that span. Thus, in order to capture variables from spans, we need to have a fairly generous span filter. In this PR, we change this span filter to include all spans except those on TRACE level.

Secondly, by default, the Sentry SDK doesn't send any spans to the backend, i.e. the sampling rate is 0. Previously, we set the sampling rate to 1.0 because the span_filter was already filtering out all non-telemetry spans. A telemetry span is a concept that we invented. It is a span that gets sampled at creation time with a probability of 1%. This is useful because creating a lot of spans is also expensive, so we don't want to do it e.g. on a per-packet basis. With just these configuration options, we now have a problem: We don't want to submit all spans to Sentry but we need the span_filter to allow all spans otherwise we can't capture the contextual fields from the span in breadcrumbs. Luckily, the Sentry SDK has another configuration option: traces_sampler.

The traces_sampler gets to compute a sampling rate for each individual span. This allows us to discard all spans from being sent to Sentry unless they are telemetry spans.

Resolves: #7386.