`sentry-tower` possibly finishes transaction too early for streaming bodies

[lcian]

In sentry-tower, SentryHttpFuture starts a transaction on first poll, but it finishes the transaction as soon as the inner service future resolves to Response<ResBody>.

This can result in arguably wrong span durations when using streaming responses (e.g. using axum::body::Body::from_stream in a HTTP handler), as the transaction is ended as soon as the server starts responding.
Instead, the span should probably last for the entire duration of the response, until the body has finished streaming (either due to normal ending of the request of some kind of error along the way).

This is up for discussion, as it should probably be checked what other SDKs/OTEL do when dealing with streaming responses and align with those approaches. So, the current behavior might be correct. But intuitively I think it's wrong.
Also, I don't know if it's possible to implement such a change without relying directly on axum, this might not be possible at the tower level.

[linear-code]

RUST-182

[szokeasaurusrex]

@lcian if you can link an example trace, that would be helpful 🙏

[lcian]

This page lists transactions for the objects:batch endpoint of https://github.com/getsentry/objectstore, which uses streaming responses.

As you can see, span.duration is always in the order of milliseconds, while I know for a fact that requests to this endpoint can take several seconds.

Here is the code for the endpoint and how the response is created.
As you can see, it's using axum::body::Body::from_stream.
This is not a very concise example but you can easily reproduce this with a simple axum app and a handler that uses from_stream, sleeping a while between chunks, or something.