After network upgrade activation, reject new connections from outdated peers

[teor2345]

Motivation

zcashd rejects new connections from outdated peers after a network upgrade activates.

Previously, the Zebra developers manually incremented the CURRENT_VERSION and MIN_NETWORK_UPGRADE version after each network upgrade activation.

But that's not an ideal solution, because it:

• causes node failures after a network upgrade activation, until the CURRENT_VERSION is incremented
• keeps connecting to old Testnet peers, until both networks have activated the same MIN_NETWORK_UPGRADE

Specifications

Original specification: ZIP 201: Network Peer Management for Overwinter

Since this is a network protocol specification, Zebra is free to adopt any compatible design.

Draft Zebra behaviour: ZIP 252: Deployment of the NU5 Network Upgrade - Support in Zebra

Solution

Increment the network protocol version after Zebra's network upgrade implementation is complete (see #1841).

Calculate the minimum peer protocol version based on the current best tip height:

• Replace MIN_NETWORK_UPGRADE with a min_peer_version function, which changes at each network upgrade activation, based on the best tip height
  • the state can use a watch channel to broadcast the best (non-finalized or finalized) tip height (the same channel as After network upgrade activation, close existing connections to outdated peers #2262)
• Add a MIN_ACTIVE_NETWORK_UPGRADE function, and use it to calculate the minimum network protocol version we'll accept during the initial sync
  • the function should take a Network argument, and (possibly) return a different network upgrade for each network
  • this function should return Canopy until after NU5 activation on each network
• If the chain is rolled back past network upgrade activation, allow connections to outdated peers again

Handshaker:

• Reject new handshakes with outdated peers based on min_peer_version
  • check inbound and outbound peers

Documentation:

• Update ZIP 252: Deployment of the NU5 Network Upgrade - Support in Zebra

Testing:

• Set the testnet activation height lower than specified, and check Zebra's behaviour
• Run and monitor Zebra nodes on testnet during activation
• TODO: what other tests can we do here, without too much effort?

Alternative Solutions

Manually increment MIN_NETWORK_UPGRADE after each network upgrade. This will cause Zebra to fail after each network upgrade, until the user installs the latest version.

Related Issues

A previous PR that incremented these constants is #1333.

#706 evicting old peers in the days before a network upgrade
#337 ZIP-200: Network Upgrade Mechanism

Follow Up

Re-deploy long-running Foundation Zebra nodes

[hdevalence]

Rather than implementing any special network upgrade disconnection logic, I think it would be much cleaner to (1) decline to connect to peers speaking the old protocol and (2) ensure that all network connections are short-lived by churning peer connections. This is better because it avoids introducing extra modes into our network code.

[hdevalence]

xref #706 with discussion on the above point

[teor2345]

Assigning this ticket to sprint 7, because it's required for testnet activation.

[teor2345]

Closed by #2519.