Consider disconnecting from peers with skewed clocks

[jvff]

Motivation

Zebra currently accepts gossiped peers without verifying the last_seen time reported. This could lead to issues when the clocks are skewed, and is planned to be handled by a separate issue (#1871). However, that only normalizes the reported times to minimize the effect of the skewed clock. There might be further gain by disconnecting from peers whose clocks are skewed too much.

For example, Zcash nodes reject blocks that are more than 2 hours in the future, compared to their local clock. So peers that are more than two hours behind consensus time can't validate blocks from other peers, while peers that are more than two hours ahead of consensus time can't generate blocks that other peers will accept.

Solution

The proposed solution is to not connect to peers that have clocks skewed more than a certain threshold. This should be discussed more to decide:

• Should peers in the future be disconnected?
• Should peers in the past be disconnected?
• What should be the thresholds used?
• What happens if the local node has a clock that's skewed above or below the thresholds?
• Should disconnections only happen if the connection slots (in PeerSet?) are full?

Alternatives

Leaving things as is isn't a big issue AFAICT, but it does lead to waste of resources because the node will spend a connection slot to communicate with a peer that might not be the optimal one to communicate with.

[teor2345]

I just tweaked the descriptions, and added the specific consensus rule.