Use changeset-based pruning for StoragesHistory and AccountHistory in RocksDB

[fgimenez]

Describe the feature

Currently, RocksDBProvider::prune_storages_history_above iterates all rows to find entries to delete, which is not scalable for large tables.

The proper approach would be to use StorageChangeSets to determine which keys need to be pruned, similar to how the pruner in crates/prune/prune/src/segments/user/storage_history.rs works, and how TransactionHashNumbers pruning fetches transactions by range.

StorageChangeSets are currently stored in MDBX, not static files. When the checkpoint is behind, the changesets are also behind, so we can't use them to determine which keys to prune. Once StorageChangeSets are moved to static files, refactor to use the changeset-based approach.

Additional context

No response

Closes RETH-161

[meetrick]

@fgimenez I put together a TODO patch based on the issue you created.
Any feedback would be greatly appreciated.

• perf(provider): optimize RocksDB history pruning with changeset-based approach #20674

[github-actions]

This issue is stale because it has been open for 21 days with no activity.