refactor!: avoid using futures crate directly

[dignifiedquire]

Due to the low maintenance and absurd high amount of unsafe code in parts of the futures crate, we are trying to avoid usage of it.

Usages are replaced with

• futures-lite : general Future and Stream tooling
• futures-sink: Sink trait
• futures-buffered: faster and safer version of Futures{Un}Ordered
• If must be futures-util for sink specific things that are missing

Breaking Changes

• iroh::node::Node does not implement Future anymore
• iroh::node::Node::shutdown() is now async and can be awaited upon to wait for the node to exit
• iroh_net::util::AbortingJoinHandles inner field is not public anymore, use the From<JoinHandle> implementation to contruct it

Followups

• Apply this to bao-tree: refactor: use futures-lite instead of futures bao-tree#49
• Apply this to iroh-io: refactor: replace futures with futures-lite iroh-io#6
• Apply this to quic-rpc: refactor: no more futures crate quic-rpc#73

[Frando]

What about we do an iroh_base::futures module with reexports from these crates? It is rather annoying to work with (and remember!) that many crates for basic concurrency utils. And we might change crates again, and then have to go through all iroh crates again.

[flub]

I think I'd be -1 on iroh_base::futures.

Maybe it's worth seeing if we can get futures denied by cargo-deny?

[flub]

is this still alive? should we get it done?

[dignifiedquire]

is this still alive? should we get it done?

this is blocked on n0-computer/quic-rpc#71

[rklaehn]

Unfortunately quic-rpc is using quite a few things from futures

• sinks
• streams

Changing the futures dependency in quic-rpc to futures-lite would mean that it does not play well with crates using the full futures crate anymore, which would be not very nice. Also, if we just use futures-sink instead of futures directly aren't we still depending on code from the futures project? So what do we gain?

I can switch quic-rpc to a combination of futures-lite and importing futures-sink. But I seriously don't see the benefit for all the work. I started, but it's a lot. There is no Either in futures_lite, no select, no SinkExt in futures_sink etc.

https://github.com/n0-computer/quic-rpc/tree/no-future

[rklaehn]

@dignifiedquire I pushed a fix to your compile errors

[rklaehn]

It would be nice if you could constrain futures_lite to the imports. But if you do use futures_lite::future that collides with the import of std::future that you sometimes have to do to use the anemic standardized futures api. So 🤷. If futures_lite would reexport the std futures stuff this would not be an issue, but I guess they did not want to do that.

Also I really don't get what was wrong with the BoxFuture and BoxStream type aliases in futures.

[rklaehn]

I don't mind losing this at all.