[P2P] chore: concurrent bootstrapping

[bryanchriswhite]

Description

Allows P2P bootsrapping to happen concurrently across known bootstrap nodes.

Issue

No issue

Type of change

Please mark the relevant option(s):

• New feature, functionality or library
• Bug fix
• Code health or cleanup
• Major breaking change
• Documentation
• Other

List of changes

• Refactored P2P bootstrapping to its own go routine

Testing

• make develop_test; if any code changes were made
• Docker Compose LocalNet; if any major functionality was changed or introduced
• k8s LocalNet; if any infrastructure or configuration changes were made

Required Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added, or updated, godoc format comments on touched members (see: tip.golang.org/doc/comment)
• I have tested my changes using the available tooling
• I have updated the corresponding CHANGELOG

If Applicable Checklist

• I have updated the corresponding README(s); local and/or global
• I have added tests that prove my fix is effective or that my feature works
• I have added, or updated, mermaid.js diagrams in the corresponding README(s)
• I have added, or updated, documentation and mermaid.js diagrams in shared/docs/* if I updated shared/*README(s)

The check succeeded, dismissing the review comment.

[dylanlott]

🚀

[bryanchriswhite]

@deblasis I'm seeing RPC health check failures during bootstrapping which were previously hidden (not being attempted). I'm not sure if it's related to the DNS updates but wanted to call it out here:

[deblasis]

@deblasis I'm seeing RPC health check failures during bootstrapping which were previously hidden (not being attempted). I'm not sure if it's related to the DNS updates but wanted to call it out here:

@bryanchriswhite 👋
At a glance, I don't recognise the validator naming convention so you might be onto something. I don't have an eye on the updated codebase but in my MVP I naively used the validator name to build the logic necessary to look for bootstrap nodes. If I remember well I left a comment explaining my train of thought.

Let me know if this helps otherwise I'll pull the updated codebase and answer with more details.

Edit: these warnings might be normal and simply indicating that one of the two bootstrap nodes that I hardcoded is not reachable but it's by design and it was meant to make sure that the fallback to the next bootstrap node worked. The comment I mentioned above should explain this.

[bryanchriswhite]

@deblasis hey! 👋 Good to hear from you and apologies for the autocomplete failure - I meant to tag @okdas. 🤦‍♂️

[Olshansk]

Slightly unrelated.

@bryanchriswhite I know you're looking into kademlia and such, and just wanted to make sure you were aware they have some of their own native configs: https://docs.libp2p.io/concepts/discovery-routing/kaddht/#bootstrap-process. Found an example here.

[okdas]

@bryanchriswhite Thank you for catching this!

1. To properly diagnose where the health check error comes from, I think we should add a status code and possibly response body (maybe in debug output?) to figure out what and how responds to the health check. Just want to double-check — this doesn't seem to be used currently? Not until we have peer discovery and possibly state sync?
2. For concurrency limiter, we already have that package, but I actually like yours more because it allows to pass a context! :)

[okdas]

Suggested change

	m.logger.Warn().Str("serviceURL", serviceURL).Msg("Error getting a green health check from bootstrap node")
	m.logger.Warn().Str("serviceURL", serviceURL).Int("code", healthCheck.StatusCode).Msg("Error getting a green health check from bootstrap node")