Start disconnecting from outdated peers a few days before network upgrade activation

[teor2345]

Motivation

To avoid Zcash peer connection storms, we want to start disconnecting from outdated peers before network upgrade activation.

Specifications

Here is what zcashd does: https://zips.z.cash/zip-0201#network-coalescence

Designs

1. If Zebra is close to a network upgrade, at regular intervals, randomly choose an outdated peer, and disconnect from it. This will make Zebra automatically reconnect to another peer in its address book.

Optional:

2. 1875 might be needed to make sure we don't just reconnect to the same peer

3. We might be able to re-use the ChangePeerConnections request from #7822, but add an "outdated peers only" filter to it.

Possible Implementation

Launch a peer set background task that waits until the block height has changed, checks if it is near a network upgrade, then sends a ChangePeerConnections { disconnect_outdated: true } request.

Then sleep until the next request could be sent, whether a request was sent or not. This avoids locking the state watch channel too much.

Out of Scope

optional changes

5. When connecting to peers, randomly choose a peer from `reconnection_peers`, rather than always choosing the first one. To prefer peers that are more likely to reconnect, randomly select two peer indexes using [sample](https://docs.rs/rand/latest/rand/seq/index/fn.sample.html), then return the peer at the lower index.

Compatibility

Here are the zcashd parameters:

• close means height >= (activation_height - NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD)
• NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD is 1728, or 1.5 days
• the regular intervals are whenever there is a new connection
• an outdated peer is a peer that would be disconnected after the upcoming network upgrade

For Zebra, we could use:

• a regular interval of 5 minutes, but only if we have more than 2 peers, and
• the same parameters as zcashd

This makes the number of disconnections 2-6 times the peer set size. (The peer limits are 75 outbound and 125 inbound peers.) So if half the peers on the network are upgraded, Zebra should be connected to 75% - 98% upgraded peers when the network upgrade activates.

[mpguerra]

Hey team! Please add your planning poker estimate with Zenhub @arya2 @conradoplg @dconnolly @oxarbitrage @teor2345 @upbqdn

[mpguerra]

We might be able to defer this issue until after testnet activation, although we might also want to test it first on testnet...

[oxarbitrage]

After internal discussions and feedback from @str4d, we have concluded the following:

• Both zebrad and zcashd have end-of-support logic. When configured correctly, EOS acts as a first barrier against incompatible peers.
• zcashd includes logic for star disconnecting peers as we approach a Network Upgrade, which is what we aim to implement in this ticket for Zebra.
• zcashd will remain the main node for NU6.
• Introducing this disconnect logic now carries a risk due to insufficient time for testing.
• This feature will be more crucial for NU7.

Therefore, we have decided to implement this feature, but it is not critical for NU6 development.