Fix dropping cached stack with Store::into_data

This commit fixes a regression from bytecodealliance#9604 where using `Store::into_data`
wouldn't properly drop a cached stack in a store like a `Drop`
destructor. The fix here is to add the `flush_fiber_stack` method into
the `into_data` here as well.

crates/wasmtime/src/runtime/store.rs

@@ -655,6 +655,8 @@ impl<T> Store<T> {
 
     /// Consumes this [`Store`], destroying it, and returns the underlying data.
     pub fn into_data(mut self) -> T {
+        self.inner.flush_fiber_stack();
+
         // This is an unsafe operation because we want to avoid having a runtime
         // check or boolean for whether the data is actually contained within a
         // `Store`. The data itself is stored as `ManuallyDrop` since we're

tests/all/pooling_allocator.rs

@@ -995,16 +995,21 @@ async fn total_stacks_limit() -> Result<()> {
     let mut store1 = Store::new(&engine, ());
     let instance1 = linker.instantiate_async(&mut store1, &module).await?;
     let run1 = instance1.get_func(&mut store1, "run").unwrap();
-    let future1 = run1.call_async(store1, &[], &mut []);
+    let future1 = run1.call_async(&mut store1, &[], &mut []);
 
     let mut store2 = Store::new(&engine, ());
     let instance2 = linker.instantiate_async(&mut store2, &module).await?;
     let run2 = instance2.get_func(&mut store2, "run").unwrap();
-    let future2 = run2.call_async(store2, &[], &mut []);
+    let future2 = run2.call_async(&mut store2, &[], &mut []);
 
     future1.await?;
     future2.await?;
 
+    // Dispose one store via `Drop`, the other via `into_data`, and ensure that
+    // any lingering stacks make their way back to the pool.
+    drop(store1);
+    store2.into_data();
+
     Ok(())
 }