Figure out good value for snapEvery parameter for LedgerDB

[edsko]

The ledger DB stores a snapshot in-memory after every snapEvery blocks. A high value means faster rollback, but also more memory usage: we might lose opportunities for garbage collection, not only due to the UTxO (or other data structures) shrinking but also from the recreated spines of these data structures when updating or extending them. It is however not at all obvious how this parameter affects performance and memory usage in absolute values; we should measure this and set snapEvery accordingly.

This is not too relevant for Byron, as rollbacks there are basically absent, but will be important for Praos.

(If it turns out that we do want a relatively high value for snapEvery, we might want to consider treating the tip-1 ledger state special also, to have specific support for the common case of rollbacks of 1.)

[edsko]

This is not essential for the first mainnet release.

[edsko]

Note that this ticket is about the in-memory snapshots; see #1264 for the on-disk snapshots.

[dcoutts]

If it turns out that we do want a relatively high value for snapEvery, we might want to consider treating the tip-1 ledger state special also, to have specific support for the common case of rollbacks of 1.

The special case of 1 looks like it may be useful for:

• Praos short forks due to slot collisions
• Forging blocks when a race condition means our chain is extended in our slot (again with a Praos slot collision)
• Clients like wallets wanting the very recent ledger state (via the local state query protocol) since they're slightly behind (processing the last block while the new one has just arrived).

[mrBliss]

@kderme's investigation in #1936 has shown that the overhead of snapEvery = 1 is acceptable and around 5% compared to snapEvery = 100. We'll go ahead with snapEvery = 1 and simplify the LedgerDB.