wrpc_transport depending on wasi on wasm target even without "net" feature

[SilverMira]

Hello, while I was trying to explore using this crate as sort of an early access way of using wasip3's stream/future types by using AsyncReadStream/AsyncWriteStream in wasip2 and dedicating a thread in running the component, I faced compilation errors.

The compilation errors came from bytecodealliance/wasm-tools#2047, and through that, I found that some of my other dependencies was using wasi@0.14 while the wrpc_transport in crates.io still uses wasi@0.13.

Temporarily overriding wrpc_transport to target this repository does fix the compilation (since this repository had already updated deps to wasi@0.14). Still, I think it would be great that wrpc_transport doesn't depend on wasi if "net" is not enabled moving forward.

[rvolosatovs]

@SilverMira would you be interested in contributing a fix for this issue?

[SilverMira]

@rvolosatovs it does not seem possible without at least introducing another feature flag on wrpc-transport crate due to rust-lang/cargo#1197

[features]
default = ["fs", "net", "io-std"]
fs = ["tokio/fs"]
net = ["tokio/net"]
io-std = ["tokio/io-std"]

tokio = { workspace = true, features = ["macros", "rt", "time"] }

[target.'cfg(target_family = "wasm")'.dependencies]
wasi = { workspace = true, features = ["std"] }

If we tried to put wasi as an optional dependency and be enabled via the net flag, we would hit compilation error from tokio instead regarding tokio/net not supported on the wasm32-wasip2 platform.

If you are ok with adding a feature like wasi-net which users building for wasm32-wasip2 target currently would need to explicitly enable for the TCP functionality, then I can make a PR in that direction.

[rvolosatovs]

What if we did not use wasi crate at all and generated the bindings using wit-bindgen directly instead?
It would be perhaps best placed in a separate crate and imported in wrpc-transport on WASI targets

E.g., we could have wrpc-wasi crate containing the bindings