Bugs in block production

[mrBliss]

1. If our current chain fragment is empty at the time we produce a block, due to data corruption or due to a clock change (moved backwards), we would connect the block we produce to Genesis instead of the tip of the ImmutableDB.

   Details

   We wouldn't actually have been able to produce this block, as ChainDB.getPastLedger would have not been able to return the ledger for the Genesis (it would exit block production with TraceNoLedgerState). Even if it could return that ledger, this block wouldn't ever be adopted. Moreover, this block would likely have been empty anyway, as the Mempool would likely have been empty because it is unlikely that we would have received transaction already but not yet blocks. Furthermore, its possible contents would have been validated against the wrong (genesis) ledger.

2. If we must strip off a block (because we received a block for the same slot from another node) and the current chain fragment is empty after that (because we're at the start of the blockchain or because of data corruption), then we'd produce a block connected to genesis.
   a. If our chain is really empty after stripping, i.e., we're at genesis, then we would produce a block with the wrong block number.
   b. If our chain is not really empty but just truncated because of corruption, then we would produce a block connected to genesis with the wrong block number (similar to case 1).

[nfrisby]

I clarified on Slack: the action item here is essentially to finish PR 1544. We'd ideally exercise more of these cases during tests, but that's going to be quite difficult and moreover will almost certainly cause most of our existing consensus-focused properties to fail. Therefore, these might be candidates for the first "unrestricted threadnet tests" where we ensure many fewer invariants in the test configuration (eg we do not ensure k+ blocks in 2k slots) and only check for extreme/fatal failures.

[mrBliss]

Fixed by #1544. Related: #1584, fixed by #1589.