8337 modify chain data pruner

[Matilda-Clerke]

PR description

Add an online option to prune pre-merge blocks from the database

Fixed Issue(s)

#8337

[garyschulte]

it would be nice to see chain pruning be contingent on the sync mode in the same way trielog pruning is. Like a typical node would want to prune pre-merge history, but a full-sync node would not.

The network pre-merge cut-off could be an empty Optional for all networks except those that have at release time entered the proto-4444 window. This way chain pruning could always be enabled, but the presence or absence of a pruning cutoff is what causes the behavior change

[Matilda-Clerke]

While it would be nice to enable pruning by default, I think users might be upset by their stored history being deleted unexpectedly.

[garyschulte]

I was originally thinking of a one-off purge of pre-merge blocks and receipts but this approach makes sense in light of the future eip-4444 moving window

[pinges]

Some comments

[pinges]

No tests added for pre merge pruning?

[Matilda-Clerke]

Not yet, but I can add some once we're happy with the code

[jflo]

Good user feedback.

[jflo]

If a network is cancun at genesis, like hoodi is, then we don't do any PRE_MERGE_PRUNING, which makes sense. We would start CHAIN_PRUNING once we got to block 256. However, 6110 doesn't activate till pectra does. Might we have an inconsistency wrt deposits in the interim between them?

[Gabriel-Trintinalia]

I also prefer using the checkpoint at Genesis for pruning configuration, as it aligns with the approach taken in #8582

[Gabriel-Trintinalia]

I believe this PR shares some similarities with #8582.

The 8582 PR includes a flag for saving only headers to the database, which we could consolidate with the flags in this PR.

Additionally, 8582 utilises the checkpoint at genesis to establish the header cutoff. I suggest we adopt the same approach here, rather than introducing new constants to NetworkName or other locations.

[ahamlat]

This is not part of the PR, but more an improvement, make the chain pruner threadpool expose the same metrics names as other thread pools.
To include the metrics in Besu Full dashboard, we need to change

MonitoredExecutors.newBoundedThreadPool(
    ChainDataPruner.class.getSimpleName(),
    1,
    1,
    ChainDataPruner.MAX_PRUNING_THREAD_QUEUE_SIZE,
    metricsSystem));

to

MonitoredExecutors.newBoundedThreadPool(
            EthScheduler.class.getSimpleName() + "-ChainDataPruner",
            1,
            1,
            ChainDataPruner.MAX_PRUNING_THREAD_QUEUE_SIZE,
            metricsSystem));

One other solution is to integrate the thread pool to EthScheduler.
This is related to the formula we're using to display the metrics of monitred thread pools

as the formula currently is something like this
/besu_executors_ethscheduler_([^_]*)_.*/

        EthScheduler.class.getSimpleName() + "-ChainDataPruner",

this change has been made

[macfarla]

needs a changelog

[Matilda-Clerke]

Latest testing, including enabling database garbage collection, shows fairly minimal impact on newPayload and FCU

[Matilda-Clerke]

Some interesting findings from the latest test run (with double execution issue fixed)

All batch sizes eventually cause some increase in newPayload execution time above baseline, but lower batch size causes it to be less impactful over a longer period of time.

[siladu]

LGTM 🚢