Entering the same span several times causes esoteric behavior

[Ten0]

How do you use Sentry?

Sentry SaaS (sentry.io)

SDK version

0.46.0

Steps to reproduce

Create a tracing span.
Enter it in a thread/task n°1 (to get the hub/subspans).
Enter it in another thread/task n°2 (to get the same hub/subspans).
Exit it in n°2
Exit it in n°1

aka

let span = tracing::info_span("foo");
let span2 = span.clone();
std::thread::spawn(move || {
    let _guard = span.enter();
    let  _guard2 = tracing::info_span("bar");
});
std::thread::spawn(move || {
    let _guard = span.enter();
    let  _guard2 = tracing::info_span("baz");
});

Expected result

They don't conflict with one another.
We should have:

<   foo >
  < bar >
  < baz >

Meaning probably, Hub of the new thread should see its current scope set to that of the span, but they should not share hubs.
(It's unclear to me why Hub is even a stack, or why it can be shared by multiple threads: AFAICT having it be active in two threads (or tasks) at the same time is always going to cause issues as it means started spans in one thread/task will be considered started within whatever the other thread/task is doing at that time, which I don't see a use-case for.)

Actual result

Due to:

sentry-rust/sentry-tracing/src/layer.rs

Line 355 in 196501d

data.hub_switch_guard = Some(sentry_core::HubSwitchGuard::new(data.hub.clone()));

entering the span on thread 2 will lead to the hub switch guard of thread 1 being dropped in thread 2, which means that thread 2 will actually not enter the hub, and then when exiting the span in thread 1 it won't actually exit the hub (because hub_switch_guard will have been left at None by thread 2).

In addition it looks like we'll bind the same hub, meaning that thread 1 entering bar may lead thread 2 to enter baz within bar instead of outside.

[linear]

RUST-132