Add pruner for finalized states

[gfukushima]

PR Description

This PR adds a state pruner that can prune finalized states keeping only the finalized states for the amount of epochs specified using the experimental flag --Xdata-storage-archive-finalized-states-retained.
Available in archive mode exclusively.

Fixed Issue(s)

Fixes #8331

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[rolfyone]

we probably want to be mindful of logs here... maybe either put this to debug, or only log this when we're in archive mode...
also probalby want to think about this service WRT tree storage mode..

[gfukushima]

yes, these are some leftovers I missed from a test. I'm doing a cleanup on some of those atm. the one that survive the clean up in the end they will all be at debug level

[gfukushima]

changed this to be a more informative log but kept it at INFO level since it is only printed at startup, WDYT?

[rolfyone]

i think if this runs during epoch transition it may get interesting, more of a general observation about all of these types of tasks i guess... we probably want to build out a design at some point that gives us more confidence about what parts of an epoch these tasks might be allowed...

[gfukushima]

tbh, this has been the most difficult part so far, to find/define a good set up, I thought about something a little more dynamic. E.g having the interval being defined by epochs_retained and epoch_durantion

[tbenr]

I agree with Paul that we could have a "no flight time window" which could be epoch transition +/- 1 or 2 slots (ie from 31 to 2). The question will be how to handle tasks falling in that window:

• skip: (pro: easy, cons: no execution guarantee for a long time)
• queue them to the end of the time window (slot 2): (pro: execution guarantees, cons: multiple tasks can potentially run at the same time)

Just dumped some thoughts.

[tbenr]

Another option is to link these prunings explicitly to certain slots, so the frequency will be an epoch for all of them, and we will have an implicit control over the epoch transition overlap (not guaranteed but reasonable).

[gfukushima]

There is a question which is, should we allow users to config --Xdata-storage-archive-finalized-states-retained to a value lower than --data-storage-archive-frequency? This would mean that you might have a finalized state for a short period of time in the DB.

Example:
--data-storage-archive-frequency = 2048 (default = 64 epochs)
--Xdata-storage-archive-finalized-states-retained = 32 (1 epoch)

You might save a finalized state for slot number 10, and by the time slot 42 reaches finalization state for slot 10 will be pruned. Next finalized state to be stored in the db will be on slot 2058 only.

[tbenr]

Next finalized state to be stored in the db will be on slot 2058 only.

I guess you intended 2048 here otherwise I'm missing something in the reasoning :)

In general I think it is an edge case, and definitely a weird configuration to have. My mild feeling would be to enforce retain to be > than frequency

[tbenr]

LGTM. some comments and still a LOG level change requested by Paul

[gfukushima]

Adding some numbers collected from instances before merging this PR:

DB Size of different setups:
Holesky-01 (minimal)
DB - 72G teku/beacon/db

Holesky-archive
DB - 212G teku/beacon/db

Holesky-archive-64epochs
DB - 110G teku/beacon/db