Use Tokio::spawn instead of getting an executor handle (#36701)

This was causing panics due to the handles being dropped out of order.
It doesn't seem possible to guarantee the correct drop ordering given
that we're holding them over await points, so lets just spawn on the
tokio executor itself which gives us access to the state we needed those
handles for in the first place.

Fixes: ZED-1R

Release Notes:

- N/A

Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>

crates/gpui_tokio/Cargo.toml

@@ -13,6 +13,7 @@ path = "src/gpui_tokio.rs"
 doctest = false
 
 [dependencies]
+anyhow.workspace = true
 util.workspace = true
 gpui.workspace = true
 tokio = { workspace = true, features = ["rt", "rt-multi-thread"] }

crates/gpui_tokio/src/gpui_tokio.rs

@@ -52,6 +52,28 @@ impl Tokio {
         })
     }
 
+    /// Spawns the given future on Tokio's thread pool, and returns it via a GPUI task
+    /// Note that the Tokio task will be cancelled if the GPUI task is dropped
+    pub fn spawn_result<C, Fut, R>(cx: &C, f: Fut) -> C::Result<Task<anyhow::Result<R>>>
+    where
+        C: AppContext,
+        Fut: Future<Output = anyhow::Result<R>> + Send + 'static,
+        R: Send + 'static,
+    {
+        cx.read_global(|tokio: &GlobalTokio, cx| {
+            let join_handle = tokio.runtime.spawn(f);
+            let abort_handle = join_handle.abort_handle();
+            let cancel = defer(move || {
+                abort_handle.abort();
+            });
+            cx.background_spawn(async move {
+                let result = join_handle.await?;
+                drop(cancel);
+                result
+            })
+        })
+    }
+
     pub fn handle(cx: &App) -> tokio::runtime::Handle {
         GlobalTokio::global(cx).runtime.handle().clone()
     }