various fixes related to stream/future cancellation

Most of this is related to the delay between queuing an event (e.g. read
completion) and delivering it; a guest could cancel inbetween, and we should
allow that rather than trap.

Also, we need to be careful to invalidate any queued events as part of
cancellation, especially given that the guest could cancel and close a stream or
future before delivery.

This code is getting uglier with time and will likely need to be cleaned up and
refactored before it is upstreamed.

Fixes #84

Signed-off-by: Joel Dice <joel.dice@fermyon.com>

Author: dicej

crates/misc/component-async-tests/tests/scenario/streams.rs

@@ -1,6 +1,6 @@
 use {
     anyhow::Result,
-    component_async_tests::{closed_streams, Ctx},
+    component_async_tests::{closed_streams, util::init_logger, Ctx},
     futures::future,
     std::sync::{Arc, Mutex},
     tokio::fs,
@@ -16,6 +16,8 @@ use {
 
 #[tokio::test]
 pub async fn async_watch_streams() -> Result<()> {
+    init_logger();
+
     let mut config = Config::new();
     config.wasm_component_model(true);
     config.wasm_component_model_async(true);
@@ -141,6 +143,8 @@ pub async fn async_closed_streams_with_watch() -> Result<()> {
 }
 
 pub async fn test_closed_streams(watch: bool) -> Result<()> {
+    init_logger();
+
     let mut config = Config::new();
     config.debug_info(true);
     config.cranelift_debug_verifier(true);