Chain Sync Client: rate limiting

The Chain Sync client can be exposed to adversarial behaviour:

* An upstream node is rapidly switching forks, e.g., producing multiple blocks
for the same slot. A reliable upstream node never produces more than one
block per slot.

* Multiple upstream nodes are collaborating in adversarial behaviour by each
producing a block for the same slot, where each block has a different hot
key (with different certificate numbers), but all hot keys are signed by the
same (compromised) cold key.

When this happens with two upstream nodes, there is no outright adversarial
behaviour, as the block signed with the hot key with the higher certificate
number "wins". This can happen when the hot key (with the lower certificate
number) was compromised and is now used by some attacker (the node sending
the first block). The reliable node then produced a new hot key with an
incremented certificate number and sent the second block.

However, when a third block is produced for the same slot with a different
hot key signed by the same cold key, there is adversarial behaviour, as no
reliable node would produce multiple new hot keys and sign blocks in the
same slot.

The Chain Sync client must perform some form of rate limiting, e.g., by
delaying the interaction with an adversarial node or by disconnecting from it
(by throwing a specific exception). There will need to be some state per
upstream node to detect this, but also some state shared among all upstream
nodes.

We should not reject these blocks based on the order in which we happen to
receive them, as this could destroy consensus. It _might_ be possible to rule
out this adversarial behaviour at the consensus level (only one replacement
block allowed, all further blocks must be regarded as invalid) but this should
be properly discussed at the level of the consensus protocol with the
researchers.