fix(webrtc example): clarify idle connection timeout

[DougAnderson444]

Description

When I ran the example/browser-webrtc example I discovered it would break after a ping or two.
The Ping idle timeout needed to be extended, on both the server and the wasm client, which is what this PR fixes.
I also added a small note to the README about ensuring wasm-pack is install for the users who are new to the ecosystem.

Fixes: #4950.

Notes & open questions

The native code can accept u64::MAX, but curiously in wasm we cannot use u64::MAX. The with_idle_connection_timeout breaks in the browser on anything bigger than 32_212_254u64

.with_swarm_config(|c| {
  c.with_idle_connection_timeout(Duration::from_secs(
   32_212_254u64,
   // 32_212_255u64, // breaks, too large for wasm?
  ))
})

The reason why this occurs is left as an open challenge for the community.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] A changelog entry has been made in the appropriate crates

[thomaseizinger]

Two comments. Also linking a related discussion / proposal: #4967.

[DougAnderson444]

Yes, 30 seconds is long enough to observe a couple of Pings.

But, I was initially surprised that the pings stopped so soon and confused as to why the pings stopped. The error log (Uncaught Error: closure invoked recursively or after being dropped) left me little evidence as to why. I suppose I expected them to ping for an extended period of time, then it just stopped after 3 pings and errored.

I didn't realize yet that Ping goes idle right away. I expected the idle to occur only if the connection dropped off (just my assumption), so I was surprised that I needed to extend the idle time to the duration that I wanted to see the pings for longer.

This could be solved by documentation in the example I suppose:

Pings the server for 30 seconds then lets the Ping go idle

And perhaps a more graceful handling of the error?

info/warn: Ping has gone idle

I'm open to either/both or additional options but I think it should be clear in the example.

So perhaps this PR should be:

1. Improve the example docs
2. Improve Ping goes idle handling (let the connection know?)

Thoughts?

[thomaseizinger]

The confusion is understandable and a bit unfortunate.

A connection being idle in rust-libp2p means that there are no streams (worth having) that need to finish executing. We explicitly exclude all ping streams from this because ping is a continuous stream that never finishes so we would never be able to shut down an idle connection.

The problem is really one of the example. Ping is a good dummy protocol to see that the connection works but it does mean we explicitly have to extend the idle timeout.

I am open to making this better but I haven't found a good solution yet. Note that there is a discussion around this here: #4912

[DougAnderson444]

Ok, thanks for your thoughts @thomaseizinger.

I think for the sake of this example, it should be more clear now that I've made the example a bit more verbose for whoever runs it in the future. If they get confused like I initially did, I suppose we'd hear about it and clarify further if needed.

In the end I am also glad it wasn't a bug in WebRTC!

[thomaseizinger]

Great changes! Thank you very much :)

If you are keen, I'd be interested in your opinion on the wider topic of idle timeouts in #4967.