Test rollback in combination with data corruption

Data corruption might leave the chain DB in a state where it is unable to roll back `k` blocks. This is due to (at least?) two factors:

* If blocks near the tip of the chain got corrupted and we truncated the chain, in principle we should now consider some blocks in the _immutable_ database to be once again mutable. We don't do this.
* The ledger DB will restore from whichever snapshot isn't ahead of the chain; it doesn't make sure to use a snapshot which supports at least `k` rollback. (It used to, but it doesn't anymore.)

This is an intentional simplification of the design, but we should test that we do deal with these cases correctly.

cc @dcoutts @nfrisby