BFT-498: Add genesis to BatchVotes operations

[aakoshh]

What ❔

Adds genesis: GenesisHash to Batch and reject votes in BatchVotes unless they have the same genesis hash as the local node.

Why ❔

To prevent replay attacks either from other chains or after a fork resulting from an L1 batch reorg.

The expected behaviour now is that BatchVotes only accepts a single vote per attester, and in the event of an L1 batch reorg the following will have to happen:

• The main node is stopped, the blocks are reverted which creates a fork and a new genesis, then the main node is restarted and serves the new batch height to resume voting from
• The external nodes detect the new genesis through the main node API and stop with an error; upon restart they fetch the new genesis and adjust their database

Once the nodes are restarted they will have the new genesis which will prevent any accidental or malicious replay of the old batch votes to them via gossip. They will pick up the new batch number on which they have to vote from the main node, and cast fresh votes on them with the correct genesis hash.

The main node won't have to adjust BatchVotes::min_batch_number down while running, because it will be restarted and will re-initialise the whole stack from scratch.

What if we don't fix this?

Without this change, a reorg can play out like this:

1. The main node is stopped, blocks are reverted, the next batch to commit goes backwards
2. The main node is restarted and reconnects via gossip to some external node which, before realising that there is a new genesis which would cause it to restart, treats it as a new gossip connection and replays all votes it has in its cache. This causes the main node to re-establish QCs with a gap, but it will fail to save them because the payload won't match, and the saving routing will eventually fail and stop the node.

I could be wrong on this, maybe they won't connect via gossip because their genesis is different. A malicious node could certainly do it, but maybe it won't happen by accident.

[pompon0]

lg, note that attestation will start failing until this pr is rolled out to both attesters.