feat: allow specifying custom relay in dumbpipe (#60)

[alx0x10]

Hello I'm back!

I thought this issue would be a good first step to get familiar with Iroh, so I started implementing the possibility to define a custom relay.
As mentioned in the issue, Sendme already supports this, so I mostly adapted that code.

Before going further and adding tests, I’d like your feedback on a few points:

• Do you think this feature makes sense here? Since Sendme already demonstrates it, maybe you prefer to keep dumbpipe shorter and focused only on the listen/connect logic?
• I introduced the anyhow dependency like in Sendme. Would you prefer a different error-handling approach? I could just implement the From<> myself.
• Like in Sendme, I wrapped RelayMode into RelayModeOption, which removes the Staging option. I haven’t really looked into how staging works, would you like me to explore that for this implementation?

[eminence]

It doesn't look like anyhow is used in your PR?

Edit: disregard, sorry, I see it now

[eminence]

Could the error type here be iroh::RelayUrlParseError?

[dignifiedquire]

would be nice to avoid the anyhow error, but other than that, looks reasonable

[alx0x10]

Ok, thank you for the feedback, I hadn't seen this RelayUrlParseError.
I made the modification and I also prefer it much more like that!

I'll look into the testing soon then and come back to you 👍

[eminence]

When running with a relay disabled, this call to home_relay().initialized() never returns, and so a ticket is never printed

[dignifiedquire]

This looks pretty good, can you fix the lint issues and move it to ready (it is still marked as draft)?

[alx0x10]

Actually, as @eminence says, when running dumbpipe with the --relay disable, the code blocks at endpoint.home_relay().initialized().await; since no home relay is initialized.

I've added a condition to not run this check if we disable the use of a relay.

    if args.common.relay != RelayModeOption::Disabled {
        endpoint.home_relay().initialized().await;
    }

And I noticed that this check is not made for the connect_stdio()... I couldn't understand the reason for it.

Also, the same issue is present on Sendme.
I opened an issue about it, once you validate the fix I can propagate it there.

Beside that I added some tests and info in the readme.

[eminence]

This help text needs a little tweaking I think.

You don't set this option to the literal value of "custom", but rather you give your relay url

[alx0x10]

Hello!

I've implemented the timeout like @dignifiedquire did in sendme.
And modified the help text.

Tell me if there is anything else I should change on this pr.

[eminence]

It feels a little weird to put the if-conditional inside the timeout. I would put the if-conditional on the outside.

Also, the 0.93.0 blog post recommends a value of 5 seconds, which is what I've implemented in my PR here

[alx0x10]

Ok thank you for the resource!
I've made the modifs.

[alx0x10]

Btw I'm not sure to understand why just let _ = the Result of the timeout instead of .expect() or something to stop if the endpoint does get online.

[alx0x10]

Maybe a warning?

if !(common.relay == RelayModeOption::Disabled)
  && tokio::time::timeout(Duration::from_secs(5), endpoint.online()).await.is_err() {
    eprintln!("Error waiting for relay connection (timeout)");
  };