Correctly deal with unknown blocks when initializing ledger DB in presence of EBBs

[edsko]

When we initialize the ledger DB, it is possible that a ledger DB on-disk snapshot refers to a block that is expected to be present in the immutable DB, but isn't. When this happens, we should discard the snapshot and try to use an older snapshot instead.

This was already implemented, but the way we checked whether the block was present was by comparing slot numbers. If the slot number of the Point required by the ledger DB was present in the immutable DB, we assumed that the block must be present. This isn't correct, however. It is possible that the immutable DB contains an EBB of that slot, by the ledger DB snapshot refers to the regular block in the same slot. In this scenario, initialization of the ledger DB failed with an internal error, and we would not attempt to try an earlier version.

[edsko]

Note that there are two ways for the on-disk ledger DB snapshot to refer to a block that is intended to be in the immutable DB, but isn't:

1. Data loss in the imm DB
2. We take a snapshot of the ledger DB, but haven't yet copied all now-immutable blocks from the volatile DB to the immutable DB.

Note that (2) is not actually all that unlikely now that we take a ledger DB snapshot when we shut down the node. We should think about this.

[edsko]

Closed in #1451.