feat(starlette): Support span streaming

[ericapisani]

Bring the Starlette integration to span-streaming parity with the FastAPI change that landed in #6118.

Under the trace_lifecycle: "stream" experiment the scope's transaction is None and the scope instead holds a StreamedSpan, so the existing middleware instrumentation (which called start_span(op=..., origin=...) + set_tag) and the profiler's current_scope.transaction.update_active_thread() hook in patch_request_response didn't function under streaming. This PR routes both through the streaming APIs when streaming is enabled while leaving the legacy transaction-based path untouched:

• _enable_span_for_middleware now uses a _start_middleware_span helper that calls sentry_sdk.traces.start_span with sentry.op, sentry.origin, and starlette.middleware_name attributes under streaming, and the existing sentry_sdk.start_span(op=..., origin=...) + set_tag otherwise.
• The profiler hook detects StreamedSpan (excluding NoOpStreamedSpan) and calls _segment._update_active_thread(); otherwise it takes the legacy current_scope.transaction.update_active_thread() branch.

Tests are parametrized across streaming and static modes for test_middleware_spans, test_middleware_spans_disabled, test_middleware_callback_spans, and test_span_origin. A new test_active_thread_id_span_streaming covers the segment's thread.id attribute under streaming. auto_enabling_integrations=False is set in streaming tests where auto-instrumented spans would otherwise leak into the captured span stream.

Refs PY-2362

[linear-code]

PY-2362 Migrate starlette to span first

[github-actions]

Codecov Results 📊

✅ 13 passed | Total: 13 | Pass Rate: 100% | Execution Time: 8.75s

All tests are passing successfully.

❌ Patch coverage is 9.09%. Project has 14790 uncovered lines.

Files with missing lines (1)

File	Patch %	Lines
starlette.py	5.63%	⚠️ 352 Missing

---

Generated by Codecov Action

[sentrivana]

Nice, left a few comments -- we'll need to migrate the event processors as well.

[sentrivana]

starlette.middleware_name is not in Sentry semantic conventions -- anything we set as an attribute on a streamed span needs to be there. So we either need to add it or not set it at all.

In this case, if I read the code right, it seems to be the same as the span name? In that case I'd omit the attribute. If we want to keep it, I'd propose a new attribute name in Sentry conventions that's not tied to Starlette specifically, so that we can use it across different frameworks and languages.

[sentrivana]

We're adding an event processor here. In legacy mode, it would enrich any transaction event with additional data. Since streamed spans are not events, it'll not apply, so anytime there's an event processor in an integration, we need to come up with an equivalent way to apply the data to streaming segments as well.

The gist is basically:

• Leave the event processor in place since it should continue working for other event types, like errors, as well, in the future.
• The span streaming version of this will basically be us setting equivalent attributes (which need to be in conventions) on the segment span.
• Event processors are normally run at the very end of the transaction lifecycle. Depending on what data they set, the span streaming equivalent might also need to be run towards the end of the segment's lifetime -- it depends on whether any of the data we set can be expected to be populated only later (like, for instance, the response status code).

Have a look at ASGI for prior art.

Ideally, this would've popped up in the tests. Looks like we're not really testing that the event processor applies the correct data, since the tests are passing even without it. That's not great. But we can also address that at a later point since it's out of scope of this PR.

[sentrivana]

We'll also need to port this event processor