Make async-nats independent on the runtime

[pimeys]

Proposed change

Hey. I think we should make async-nats independent from tokio. While tokio remains the standard in the async Rust ecosystem, stable Rust has now standardized wasip2, and we can handle almost all IO with the second preview.

Tokio lacks wasip2 support. The team waits for mio to support it, but the pull request in mio has remained pending since last November without signs of merging soon.

Until Tokio adds support, we can use a temporary runtime in a p2 guest component: wstd

The lack of standardized Rust runtimes means we must use the runtime's TCP implementation. I want to examine the async-nats codebase to understand your tokio dependencies. Could we create a way to initialize nats by providing a socket that implements the AsyncRead and AsyncWrite traits? I hope you don't use tokio::spawn, or at least we could abstract these with a feature flag setup. The same applies to timers. This change shouldn't be too complex, and it would let us write wasip2 components that can use nats without implementing everything in the host.

Use case

To use nats in environments without tokio support.

Contribution

I am interested on providing a pull request, if this is a path you'd like to see for async-nats.

[Jarema]

Hey.

We decided to land on tokio runtime, as you said, it's Rust standard.

AsyncRead and AsyncWrite is already used, but it might get more complex than it seems to become agnostic over runtime.
Additionally, we do use tokio::spawn, but in just few places.
Timers are also used, but again, quite sparingly.

I encourage to do POC, however keep in mind that it's important to keep maintainability of the codebase and performance.

[pimeys]

Yeah, we are aiming to support wasi extensions on wasmtime runtime this spring, and we want to build a nats extension on Grafbase this sprint. We could do the nats connection in the host, and provide it over the wit definition to the guest, but that is kind of not great showcase on what we can do with wasip2.

So in the coming weeks I'm either forking async-nats and making it agnostic on runtime for our use, and send a PR if you want to have it part of the mainline. Or I will make mio and tokio to work with p2 and get my changes mainlined there. I need to think which route is less friction...

[pimeys]

As a note, I've written one Rust crate already that is agnostic on runtime. So it's doable:

https://github.com/prisma/tiberius