fix(p2p): make bootstrapping non-blocking

[Wondertan]

We were waiting for all bootstrapper connections to either fail or succeed. The side effect of this approach is that a single connection may stall for various reasons, preventing the Exchange client from starting in an adequate amount of time.

This patch ensures that every connection attempt has a generous timeout of 1m and that connections are not blocked for startup. We don't, in fact, need to wait for any connection to succeed and continue application startup. This also optimizes the startup time in the best case, as the application would be able to operate with new connections as they come and established, instead of waiting for the whole group of bootstrapper connections to either fall or succeed.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.02%. Comparing base (bdda26a) to head (e0c6a97).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #167      +/-   ##
==========================================
+ Coverage   62.87%   63.02%   +0.15%     
==========================================
  Files          39       39              
  Lines        3577     3573       -4     
==========================================
+ Hits         2249     2252       +3     
+ Misses       1155     1150       -5     
+ Partials      173      171       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[walldiss]

Does removing of waitgroup imply, that it doesn't need to wait for any connections to succeed anymore before returning from bootstrap()? Is it ok if all of the (or some) fail?

[Wondertan]

Is it ok if all of the (or some) fail?

yes

Does removing of waitgroup imply, that it doesn't need to wait for any connections to succeed anymore before returning from bootstrap()?

Also yes, with a little caveat. The waiting for connections will still happen on the libp2p swarm level, if application decides to request anything and connections are still in progress

[walldiss]

Just trying to understand what happens here. Looks like bootsrap() is acting as an optional call, since it does not wait for any connections and does not even has retries. So there might be 0 connections in the end. Does bootsrap() suppose to provide some connections to peer-tracker? If all of the connection fail would it result in some unwanted state? Would it make sense to add reconnects inside bootsrap in case 0 successful connections happened?