feat(iroh)!: make ProtocolHandler use async functions

[Frando]

Description

This changes the ProtocolHandler trait so that the functions return impl Future instead of BoxFuture, which means implementors can simply implement the trait with async fn. We don't even need a 'static bound on these futures, so you can use &self freely without cloning and moving.

Internally, we still box the futures return by accept, on_connecting and shutdown. So performance wise this change should not have any effects. But the boxing is hidden from the user and implementing the trait now feels a lot more normal and simpler.

Breaking Changes

• iroh::protocol::ProtocolHandler methods now return impl Future instead of BoxFuture. You can simply remove the Box::pin(async move {}) from the implementations and instead implement the methods as async fn. See the updated documentation for the iroh::protocol module for an example.
• iroh::protocol::ProtocolHandler is no longer dyn-compatible. If you need a dyn-compatible version, you need to build your own dyn-compatible wrapper trait. See the (non-public) DynProtocolHandler in iroh::protocol as an example.

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.
  • List all breaking changes in the above "Breaking Changes" section.
  • Open an issue or PR on any number0 repos that are affected by this breaking change. Give guidance on how the updates should be handled or do the actual updates themselves. The major ones are:
    • quic-rpc
    • iroh-gossip
    • iroh-blobs
    • dumbpipe
    • sendme

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3320/docs/iroh/

Last updated: 2025-05-20T11:35:33Z

[github-actions]

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: c4a930d

[rklaehn]

Thanks for trying this. My experience explaining Pin<Box<dyn Future...>> to very well meaning, almost enthusiastic, rust newbies, was not great. I felt a bit embarrassed for rust.

So the only overhead I can see is that if you for some reason already have a Pin<Box<dyn Future ...>>, I will have to return that as a impl Future, and it will be boxed again. But given that this interface is very high level, not the hot part of a low level function, I think it does not matter at all.

So I am very much in favour of this before 1.0.

[matheus23]

This makes me happy. DynProtocolHandler is fully internal as far as I can tell, so I think this is good!

If a user ends up double-boxing their accept futures and that indeed becomes a problem for them, well at that point they're such a power-user that switching away from the Router shouldn't be a problem for them IMO.