Active bootstrapping

[Stebalien]

Follow-up to #384.

Currently, if we completely disconnect from all peers, there's no way for the DHT to bootstrap.

Proposal:

1. Add a Bootstrap option to the dht for passing bootstrapping configuration when constructing the DHT. The current "thou shalt call Bootstrap when ready" API is confusing to new users.
2. Deprecate the current bootstrap methods in favor of a single Bootstrap(ctx, options...) method that:
3. Triggers a bootstrap iff we have no peers in the routing table (or if a "force" option is passed).
4. Waits for at least one connection before returning (more?).
5. Watches the routing table and, when it completely empties, calls Bootstrap(ctx) (connecting to the known bootstrap nodes).
6. Calls Bootstrap(ctx) on a timer (i.e., keeps trying to connect to known good nodes when the routing table is empty).
7. Calls Bootstrap(ctx) before every query. Right now, queries will simply fail in this case leading to the dreaded "failed to find any peers in table" error.

In the future, once we better track good peers, we could use peers from the peerstore instead of (or to augment) the known peer list. But we can do that later.

[aarshkshah1992]

@Stebalien Please can you assign this to me ? I think there could be some overlap with #383. Let me get back to you with some notes.

[aarshkshah1992]

After #383 & #384 are merged:

TODO

• Use the seeder with known bootstrap peers/Default peers to populate the RT when it's empty.

• Have a dedicated proc for RT recovery. Refer to this comment by @Stebalien for ideas on how to implement & call this proc.

• Before running periodic bootstrap(query for self / buckets that haven't queried for an hour), use the above proc if RT is empty.

[raulk]

Yes, the Seeder/Snapshotter abstractions were designed in that way precisely to be called we need to recover from a poisoned/blank routing table. There is also the FallbackPeers construction, which should always point to the bootstrap peers for better resilience.

[aarshkshah1992]

@aschmahmann @Stebalien

Till when do we want to punt this ? Put another way, when will we have enough confidence in our current RT management logic to land this ?

[Stebalien]

Honestly, as long as we use a bootstrapper and random peers from the last routing table, we should be fine here.

[burdiyan]

How does this overlap with what Boxo is doing in its bootstrap package?

https://github.com/ipfs/boxo/blob/main/bootstrap/bootstrap.go