Suggestion: Use futures_io traits in public API

[rrauch]

Submitting this as a draft to get your thoughts.

This swaps tokio::io::{AsyncRead, AsyncWrite} for futures_io::{AsyncRead, AsyncWrite} in the public API.

In the case of sia_sdk it entirely removes Tokio as a hard dependency.

What's the point?

Tokio comes with its own async I/O reader & writer traits: tokio::io::{AsyncRead, AsyncWrite}, while futures_io::{AsyncRead, AsyncWrite} are the runtime-agnostic versions of these traits. Both trait-families are very similar, but not identical. The futures_io traits are part of the futures project, basically the ecosystem's common ground for async that isn't tied to any specific runtime. The futures-crates are small, composable, and it's what most crates use when they want to stay neutral. tokio_util comes with a Compat wrapper that turns tokio::io::{AsyncRead, AsyncWrite} into their futures_io equivalent (and vice-versa).

By switching to the futures_io traits, Tokio becomes more of an implementation detail than a fixed part of the API.

What has changed

In terms of what changes where:

• sia_sdk - Tokio goes away as a dependency completely. Also re-exports futures_io::{AsyncRead, AsyncWrite} so consumers don't need to pull in the crate separately.
• indexd - still uses Tokio internally (uses Compat in some places), but the public API no longer forces Tokio types on consumers. This opens the door to relaxing the Tokio dependency further in the future.
• indexd_ffi - Keeping the internal Tokio runtime here makes sense. Adapted to use new API types internally.
• sia-sdk-derive - not affected

Let me know what you think, happy to rework or close this if it's not the direction you want to go.

[n8mgr]

Out of curiosity is there a major benefit to this? We're relatively new to the Rust ecosystem. It seems like there are really only two maintained runtimes with Tokio being recommended for 99% of uses.

Relaxing it in sia_sdk doesn't necessarily benefit anyone since most users will probably use indexd or indexd_ffi which both require Tokio runtimes. My understanding would be that effectively supporting another runtime would preferably be feature-gated to avoid two separate schedulers in one process?