ChainDB current chain: consider to trim based on weight

[amesgen]

Currently, the current chain is defined to be the latest k blocks on our selection (unless in edge cases like when we are near genesis or the VolDB got deleted/corrupted). A natural idea for Peras to define it take the newest n blocks where n is minimal such that the resulting chain has at least weight k (note that k might need to increase somewhat from its current mainnet value of 2160 for the same security level).

See here for where this currently happens in the code.

The upside of this it that it would make it very explicit that blocks with sufficient weight on top of them are really immutable. Also, it would improve performance in the common case (everything involving the current chain; initial chain selection gets faster; fewer ledger states stored in memory (might lose relevance with UTxO HD)), but this might also be a downside when we think about the "average case == worst case" design principle.

The goal of this ticket is to assess the impact of this change, as the current chain is used pervasively. For example, the LedgerDB needs to track a ledger state for each block on the current chain, so it might be impacted.