ChainSync client: allow to prevent historical MsgRollBackward/MsgAwaitReply

[amesgen]

This PR enables the ChainSync client to disconnect from peers who send historical MsgRollBackward and MsgAwaitReply messages, ie rollbacks that no honest caught-up peer would send as the corresponding blocks are already immutable for them, and MsgAwaitReplys that would indicate a chain whose tip is way behind the wall-clock.

This is relevant for the ChainSync Jumping (CSJ) optimization (part of Ouroboros Genesis): CSJ handles MsgAwaitReply and rollbacks to before a point that a peer previously acknowledged by "disengaging" that peer, ie running full ChainSync with them. This is the right thing to do when we are almost caught-up; however, during syncing the historical chain, this causes extra network load (albeit symmetrical) and CPU load.

We define a MsgRollBackward/MsgAwaitReply to be historical if the Genesis State Machine has not yet concluded that we are caught up and the wall-clock time of the slot of the oldest rewound header (if any) or the previous tip of the candidate fragment, respectively, is older than a configuration value, the historicity cutoff. In this PR, we set it to the duration of one mainnet stability window plus one hour as extra margin (so 36 h + 1 h = 37 h). Future work might include getting this duration out of the HFC.

We also modify the existing ChainSync client test to test for false positives; false negatives can be tested by manually modifying the code (such as subtracting a constant from historicityCutoff, or introducing bugs in the actual implementation); we defer a standalone test for false negatives (similar to #526).

The PR is intended to be reviewed commit by commit.

[amesgen]

A future test for false negatives (eg one that ensures that running with maxRollbackAge - 1 sometimes fails) would catch if the generator changed in the future; but I think this is fine for now.

[nfrisby]

Looks good! Thanks for switching approaches.

[dnadales]

Isn't this too Cardano specific? And somewhat related, is it ok to have these constants hardcoded here?

[amesgen]

Yes, this is specific to Cardano mainnet; like many other constants in this area (e.g. the timeouts, protocol-level size limits, the GSM MaxCaughtUpAge).