rt: EnterGuard should not be Send (#5766)

Removes `Send` from `EnterGuard` (returned by `Handle::enter()`. The
guard type changes a thread-local variable on drop. If the guard is
moved to a different thread, it would modify the wrong thread-local.

This is a **breaking change** but it fixes a bug and prevents incorrect
user behavior. If user code breaks because of this, it is because they
(most likely) have a bug in their code.

tokio/src/runtime/context.rs

@@ -159,6 +159,9 @@ cfg_rt! {
     pub(crate) struct SetCurrentGuard {
         old_handle: Option<scheduler::Handle>,
         old_seed: RngSeed,
+        // Should not be `Send` since it must be *dropped* on the same thread as
+        // created, but there is no issue with sync access.
+        _p: PhantomData<crate::util::markers::SyncNotSend>,
     }
 
     /// Guard tracking that a caller has entered a runtime context.
@@ -308,6 +311,7 @@ cfg_rt! {
             SetCurrentGuard {
                 old_handle,
                 old_seed,
+                _p: PhantomData,
             }
         }
     }

tokio/src/util/markers.rs

@@ -0,0 +1,4 @@
+/// Marker for types that are `Sync` but not `Send`
+pub(crate) struct SyncNotSend(*mut ());
+
+unsafe impl Sync for SyncNotSend {}

tokio/src/util/mod.rs

@@ -79,3 +79,5 @@ pub(crate) mod error;
 
 #[cfg(feature = "io-util")]
 pub(crate) mod memchr;
+
+pub(crate) mod markers;

tokio/tests/async_send_sync.rs

@@ -532,7 +532,7 @@ async_assert_fn!(tokio::task::unconstrained(BoxFutureSend<()>): Send & !Sync & U
 async_assert_fn!(tokio::task::unconstrained(BoxFutureSync<()>): Send & Sync & Unpin);
 
 assert_value!(tokio::runtime::Builder: Send & Sync & Unpin);
-assert_value!(tokio::runtime::EnterGuard<'_>: Send & Sync & Unpin);
+assert_value!(tokio::runtime::EnterGuard<'_>: !Send & Sync & Unpin);
 assert_value!(tokio::runtime::Handle: Send & Sync & Unpin);
 assert_value!(tokio::runtime::Runtime: Send & Sync & Unpin);