Chain DB: test with corruption

Currently, when an unexpected (file-system) error is encountered, the ChainDB is closed and the whole node is shut down. Restarting the node should trigger recovery (#1200).

- [ ] Test that unexpected errors shut down the node
- [ ] Unexpected errors in the iterators
- [ ] Unexpected errors in the readers
- [ ] Unexpected errors in the background threads
- [ ] Check that no file handles are leaked
- [ ] Simulate corruptions and see how the node recovers

Notes:

> Important: including when using iterators and readers.
> Some calls to the ImmutableDB, the VolatileDB, or the LedgerDB encountered corruption: see what happens and whether the other DBs are properly synched/recovered/whatever.
>
> Don't try to be too clever, because we might miss some tings: just simulate errors using the existing error simulation infrastructure. The underlying database will notice and the recovery will be triggered.
> But don't simulate things like: a block was not written to disk, but then a GC happened afterwards, etc.
>
> We can add a command that triggers garbage collection: this can hopefully trigger the race conditions in the iterators that have to deal with blocks moving between databases. The GC command will have no parameters, it will just perform the scheduled GC. Also see the last section in ChainDB.md.