cros_async: test blocking pool handle drop behavior

This was implicitly tested before, but seems worth an explicit test.

Change-Id: I0d31051a8422d61f91938fc5975f230346bbce65
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4478450
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>

cros_async/src/blocking/pool.rs

@@ -369,6 +369,19 @@ mod test {
         assert_eq!(res, 42);
     }
 
+    #[test]
+    fn drop_doesnt_block() {
+        let pool = BlockingPool::default();
+        let (tx, rx) = std::sync::mpsc::sync_channel(0);
+        // The blocking work should continue even though we drop the future.
+        //
+        // If we cancelled the work, then the recv call would fail. If we blocked on the work, then
+        // the send would never complete because the channel is size zero and so waits for a
+        // matching recv call.
+        std::mem::drop(pool.spawn(move || tx.send(()).unwrap()));
+        rx.recv().unwrap();
+    }
+
     #[test]
     fn fast_tasks_with_short_keepalive() {
         let pool = BlockingPool::new(256, Duration::from_millis(1));