Experiment: two stage builder approach for custom protocols

[rklaehn]

Description

This is like #2358, but instead of having a factory function to create a protocol, it uses a two stage builder approach where you first build a non-accepting node, then add all the promised handlers, and then turn it into a full (accepting, rpc active) node.

Note that I have also changed the signature of the protocol handlers, but that is unrelated to the main difference and a matter of taste I guess. In one case you leave it up to the handlers to make a future long lived, in the other case you force the client to arc the handlers...

Breaking Changes

Notes & open questions

Change checklist

• Self-review.
• Documentation updates if relevant.
• Tests if relevant.
• All breaking changes documented.

[rklaehn]

The custom_protocols example could be made to look like this:

#[tokio::main]
async fn main() -> Result<()> {
    setup_logging();
    let args = Cli::parse();
    // create a new node
    let node = iroh::node::Node::memory()
        .accept(EXAMPLE_ALPN)
        .build();
    let proto = ExampleProto::build(&node);
    node
        .add_handler(EXAMPLE_ALPN, proto))
        .spawn()
        .await?;

Due to the two stage nature you need to use the EXAMPLE_ALPN twice, once before building the unspawned node and once as you add the handler.

I think it is nice, but not quite as compact as the factory fn approach. On the plus side, there is no Box::pin(async move { Ok( needed, and internally the ProtocolMap does not require a RwLock.

For the small example this does not show, but for a more complex one there is also this: in case of the builder fns you have to document in what order the builder fns will be called (I guess in the order in which they are added). For the two stage builder the initialization order is just explicit - whatever code you write between creation of the non-listening node and the spawn.

The iroh internal protocols could be made available on the UnspawnedNode with a similar mechanism as in the other PR, so you could refer to them.

[rklaehn]

Looks like we can change the ALPN set once the endpoint is created. With that, we get:

#[tokio::main]
async fn main() -> Result<()> {
    setup_logging();
    let args = Cli::parse();
    let node = iroh::node::Node::memory()
        .build();
    let proto = ExampleProto::build(&node);
    node
        .add_handler(EXAMPLE_ALPN, proto))
        .spawn()
        .await?;

and can remove the duplicate use of the ALPN parameter.

[rklaehn]

Folded into #2358