Beginning of peerset implementation.

[hdevalence]

So far this just has initial work following design discussion with @dconnolly this afternoon.

TODO:

• peerset can receive new peers from service discovery
• peerset can load balance over existing peers
• discovery implementation exists
• peerset backpressure creates new peers
• peersets can be instantiated in connect
• seems to connect to live network?

[hdevalence]

We noticed that there's an advantage to having a generic Discover implemenation, namely that a Discover impl that produces PeerClients can be wrapped in one that produces clients with load information (which has a different concrete type). However that means that the PeerSet cannot feed produce-a-new-peer requests directly via a method call (as it cannot call any methods beyond those provided by the trait).

[hdevalence]

Perhaps as an initial step, it would be good to separate the backpressure-drives-peerset-expansion component from this PR and deal with that separately and subsequently, which would allow using, e.g., the ServiceStream Discover impl to start instead of writing our own.

[hdevalence]

The "wip" commit stubs above change connect to build a peerset using a collection of peers from a single getaddr request. If these were cleaned up they would tick the last two boxes above, leaving only the custom Discover implementation and the auto-expansion of the peerset. Perhaps those two items would be better in a subsequent issue / PR, since doing them properly requires making calls to the peerset?

[hdevalence]

This is ultimately because failure::Error doesn't implement Clone; fixing it properly requires reworking other error handling (to use custom Fails) and I would like to wait two weeks to do it rather than do it now, if that's OK with others

[hdevalence]

Per slack discussion, dropping the middle two tasks for a subsequent PR.

[dconnolly]

LGTM ✅

[hdevalence]

Rebased onto main