Depend on accesskit with tokio feature instead of defaults

[jakobhellermann]

I added rfd using tokio to my dependencies, and got a crash in my logs.

It seems like this happens when accesskit_unix does not have the tokio feature, but zbus does.
Since xilem already depends on tokio I thought it would make sense to choose it as an executor for accesskit as well.

thread '<unnamed>' (26282) panicked at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/abstractions/executor.rs:189:27:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
stack backtrace:
18:46:27.082Z DEBUG rescan: 181.521772ms
   0: __rustc::rust_begin_unwind
             at /rustc/040a98af70f0a7da03f3d5356531b28a2a7a77e4/library/std/src/panicking.rs:698:5
   1: core::panicking::panic_fmt
             at /rustc/040a98af70f0a7da03f3d5356531b28a2a7a77e4/library/core/src/panicking.rs:75:14
   2: core::panicking::panic_display
             at /home/jakob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:259:5
   3: tokio::runtime::scheduler::Handle::current
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.47.1/src/runtime/scheduler/mod.rs:93:27
   4: tokio::runtime::blocking::pool::spawn_blocking
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.47.1/src/runtime/blocking/pool.rs:184:14
   5: tokio::task::blocking::spawn_blocking
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.47.1/src/task/blocking.rs:207:9
   6: zbus::abstractions::executor::Task<T>::spawn_blocking
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/abstractions/executor.rs:189:27
   7: zbus::address::transport::Transport::connect::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/address/transport/mod.rs:112:30
   8: zbus::address::Address::connect::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/address/mod.rs:59:34
   9: zbus::connection::builder::Builder::target_connect::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/connection/builder.rs:528:41
  10: zbus::connection::builder::Builder::connect::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/connection/builder.rs:455:78
  11: zbus::connection::builder::Builder::build_::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/connection/builder.rs:384:50
  12: zbus::abstractions::executor::Executor::run::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/abstractions/executor.rs:122:20
  13: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /home/jakob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/future.rs:133:9
  14: zbus::connection::builder::Builder::build::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zbus-5.10.0/src/connection/builder.rs:370:74
  15: accesskit_unix::context::get_or_init_messages::{{closure}}::{{closure}}::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/accesskit_unix-0.17.0/src/context.rs:59:95
  16: <futures_lite::future::Or<F1,F2> as core::future::future::Future>::poll
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/futures-lite-2.6.1/src/future.rs:451:46
  17: async_executor::State::run::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/async-executor-1.13.3/src/lib.rs:758:32
  18: async_executor::Executor::run::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/async-executor-1.13.3/src/lib.rs:344:34
  19: accesskit_unix::executor::Executor::run::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/accesskit_unix-0.17.0/src/executor.rs:85:39
  20: futures_lite::future::block_on::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/futures-lite-2.6.1/src/future.rs:96:35
  21: std::thread::local::LocalKey<T>::try_with
             at /home/jakob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:315:12
  22: std::thread::local::LocalKey<T>::with
             at /home/jakob/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:279:20
  23: futures_lite::future::block_on
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/futures-lite-2.6.1/src/future.rs:75:11
  24: accesskit_unix::util::block_on
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/accesskit_unix-0.17.0/src/util.rs:13:5
  25: accesskit_unix::context::get_or_init_messages::{{closure}}::{{closure}}
             at /home/jakob/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/accesskit_unix-0.17.0/src/context.rs:57:17

[DJMcNab]

This makes sense as the default for Xilem as things stand, but I don't think it makes sense for Masonry Winit.
As such, can we instead do async-io/tokio feature flags on Masonry Winit, which then get passed through to accesskit_winit, and then enable the tokio feature on masonry_winit in Xilem?

[xStrom]

This definitely makes sense from the Xilem perspective.

However, accesskit_unix comes via Masonry which doesn't depend on Tokio and so ideally Masonry would not influence this choice at all. Not sure that we can do much about it though. Especially as accesskit_unix does not follow Rust best practices and doesn't have additive features. Which means that we can't have both a default choice of an executor and also offer a choice to override it. At least not without breaking things like --all-features and --no-default-features. It's kurbo#481 all over again, with a slightly different flavor.

Longer term this needs help from Cargo. It's an ancient issue and we have a Pre-RFC: Mutually-excusive, global features with some discussion but an actual solution in stable Rust seems years away. 😟

So once again, I think the pragmatic choice here is to just merge this and live with Tokio being the choice for Masonry too.

[DJMcNab]

Taking another look at Kaur's message (I had originally assumed it raced with mine), I realise that his analysis is correct, and so we should land this. This is an annoying situation, but I agree that this is less bad.

Thanks!