Trie log prune using TrieLogEvent

[gfukushima]

PR description

This PR aims to make the pruning logic async as this feature does not need to be in the synchronous.

Fixed Issue(s)

Part of #5390

Testing

Tested locally on a small chain.

Tested with a fresh holesky sync...

TrieLogPruning happening on an EthSchedule-Services thread...

{"@timestamp":"2024-01-19T03:04:01,050","level":"TRACE","thread":"EthScheduler-Services-4","class":"TrieLogPruner","message":"adding trie log to queue for later pruning blockNumber 765656; blockHash 0xfd2e15c6ed1d00ee050210f427869d9ff6773555e5b738888fd9855b3251ad31","throwable":""}
{"@timestamp":"2024-01-19T03:04:01,050","level":"TRACE","thread":"EthScheduler-Services-4","class":"TrieLogPruner","message":"min((chainHeadNumber: 765655 - numBlocksToRetain: 512) = 765143, finalized: 765587)) = retainAboveThisBlockOrFinalized: 765143","throwable":""}
{"@timestamp":"2024-01-19T03:04:01,050","level":"TRACE","thread":"EthScheduler-Services-4","class":"TrieLogPruner","message":"pruned 1 trie logs for blocks {765143=[0x607bc6df9eabdb70a153dc23983a384c62cfd05a46a60584716cc4114c6c0ba3]}","throwable":""}
{"@timestamp":"2024-01-19T03:04:01,050","level":"DEBUG","thread":"EthScheduler-Services-4","class":"TrieLogPruner","message":"pruned 1 trie logs from 1 blocks","throwable":""}
{"@timestamp":"2024-01-19T03:04:01,052","level":"INFO","thread":"vert.x-worker-thread-0","class":"AbstractEngineNewPayload","message":"Imported #765,656 / 18 tx / 16 ws / base fee 1.04 gwei / 4,272,115 (14.2%) gas / (0xfd2e15c6ed1d00ee050210f427869d9ff6773555e5b738888fd9855b3251ad31) in 0.093s. Peers: 25","throwable":""}

Post sync, besu (on holesky) is only maintaining a single EthScheduler-Services thread so thread contention is low (it's a cachedThreadPool).

Tasks per second during and after sync...

[github-actions]

• I thought about documentation and added the doc-change-required label to this PR if updates are required.
• I thought about the changelog and included a changelog update if required.
• If my PR includes database changes (e.g. KeyValueSegmentIdentifier) I have thought about compatibility and performed forwards and backwards compatibility tests

[jframe]

This cast doesn't look necessary

[siladu]

good spot, removed

[siladu]

remarking as draft while adding in the async piece

[siladu]

Might have been more obvious to pass EthScheduler in here but that would mean making the core module depend on the eth module which is circular.

I do like the way this is decoupled from the EthScheduler implementation anyway, even if the type is a little unobvious.

[jframe]

The Executor would be clearer than using a Consumer<Runnable> type

[siladu]

As discussed, while it happens to be the same type, the implementation I'm using does not actually represent an Executor implementation (rather a delay execution of a submission to one 😅 )