Maintain peer list for fetching blockchain data

[anorth]

Description

The current bitswap-based chain fetch mechanism does its own peer management. We intend to switch to using graphsync (or maybe #2065) which will need peers from which to fetch to be explicitly specified.

Implement a small object which maintains a list of peers discovered (through bootstrap config and DHT traversal). This should store the results of "hello" protocol exchanges so it knows the head and height (later: protocol version information) about each peer. Decouple a bit from the so that the syncer can distinguish initial chain sync from ongoing (#1105).

This object should expose a method for selecting one or more peers from which to fetch chain data, to be consumed by a graphsync-based fetcher. There should be some functionality for the fetcher to report a peer as not responding and hence suspending or evicting it.

Later, this object will run the secure bootstrapping mechanism of discovering many random peers and seeking a majority agreement on head CID before syncing a chain (#2674). Right now, we just rely on configured trusted bootstrap nodes.

cc @frrist @hannahhoward

Acceptance criteria

• An object maintains a list of peers with some state, and can provide peers to a fetcher

Risks + pitfalls

Libp2p does some implicit things, we don't want the higher level peer list to fall out of sync with peers actually connected.

Where to begin

Begin with the current hello protocol and understanding existing peer bootstrap and discovery. Decouple from the chain syncer.

[anorth]

See also some discussion in #1105. I'm not sure if that means that bootstrapping and peer management need necessarily be linked now, though.

[taoshengshi]

Who will provide this kind of peer nodes ? How to mitigate Eclipse attacks to new comers and DDoS attacks to these peers ?

[anorth]

That's a problem for #2674, which we are not addressing yet (but will soon).

[taoshengshi]

@anorth clear, thanks!

[anorth]

Done in #3163, #3184