Minimize exposure to exact immutability criterion

[amesgen]

This PR tries to isolate as much code as possible from the exact criterion for whether a block is immutable. Instead of directly using the Praos criterion ("a block is immutable iff it is buried under at least k blocks"), we instead rely on getCurrentChain to return the volatile suffix of our chain, with its anchor being the most recent immutable block.

This way, the upcoming implementation of Ouroboros Peras (#1594) will not require touching this code, despite modifying the criterion for immutability to be "a block is buried under at least k weight".

Concretely, this PR adapts the following places:

• A trace message emitted during chain selection.
• The ChainDB background logic for copying blocks to the ImmutableDB and garbage-collecting them from the VolatileDB.
• The LedgerDB logic, namely acquiring Forkers and rolling back.
• An overzealous assertion in the ChainSync client.

For now, without Peras being implemented, the actual logic doesn't change at all; we still always use Praos-based immutability.

---

Note that there are still millions of comments that implicitly consider "immutable" and "buried under k blocks" to be the same thing; it seems acceptable to defer adapting those.

---

Based on top of #1513 to avoid conflicts

Necessary for tweag/cardano-peras#71, preparation for #1594

[dnadales]

In the previous comment, it was clear when blocks were copied from the immutable to the volatile DB. However, I find the current condition a bit hard to understand. Isn't getCurrentChain always a suffix of "the chain"?

[amesgen]

What about

-- We watch the 'cdbChain' for changes. Whenever it is longer than
-- 'getCurrentChain' (the volatile suffix of 'cdbChain'), then new blocks (a
-- prefix of 'cdbChain') became immutable, and are copied from the VolatileDB to
-- the ImmutableDB (using 'copyToImmutableDB').

?

[amesgen]

Now:

-- Wait until the current chain ('cdbChain') is longer than its volatile suffix
-- ('getCurrentChain'). When this occurs, it indicates that new blocks have
-- become immutable. These newly immutable blocks are then copied are copied
-- from the VolatileDB to the ImmutableDB (using 'copyToImmutableDB').

[fraser-iohk]

remove "are copied"