Turn the CandidateSet and AddressBook into tower Services

[teor2345]

Is your feature request related to a problem? Please describe.

In Zebra, we use tower Services for most of our internal APIs.

The AddressBook and CandidateSet act like services, but they are actually custom structs with their own APIs. This makes Zebra harder to maintain and debug.

Describe the solution you'd like

• Finish the refactors and security fixes for zebra-network, so the API is stable
• Write a design RFC for the AddressBook and CandidateSet as tower Services
  • Work out how to test for deadlocks and livelocks
  • Share the AddressBook using a Buffer, rather than Arc<Mutex<_>>
  • Move the CandidateSet::next rate-limit to the outbound handshaker, using a tower::RateLimitLayer
  • Continue to ignore repeated CandidateSet::update requests within the update time limit
  • Continue to mark peers as AttemptPending before their addresses are returned
• Implement the design
• Write tests for deadlocks and livelocks

Describe alternatives you've considered

We could do nothing, and Zebra will continue to work well.

We could use a futures-aware mutex for the address book: https://docs.rs/futures/0.3.13/futures/lock/struct.Mutex.html

Additional context

We're still working on a bunch of security fixes that will change the APIs for these services.

This change risks re-introducing deadlocks and livelocks, so it needs to have tests for various edge cases.

[teor2345]

This refactor would be useful, but it's not needed right now.

[arya2]

@mpguerra This is the address book refactor that can wait until after zcashd deprecation.