Feature: Add block pruning module for historical blockchain data cleanup

[jason-aelf]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 97.10145% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.64%. Comparing base (9f729e2) to head (1c677f2).

Files with missing lines	Patch %	Lines
...ckPruning/NewIrreversibleBlockFoundEventHandler.cs	91.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #3641      +/-   ##
==========================================
+ Coverage   90.62%   90.64%   +0.01%     
==========================================
  Files         680      685       +5     
  Lines       26298    26367      +69     
  Branches     2369     2372       +3     
==========================================
+ Hits        23833    23900      +67     
- Misses       2350     2352       +2     
  Partials      115      115              

Files with missing lines	Coverage Δ
...el.BlockPruning/Application/BlockPruningService.cs	100.00% <100.00%> (ø)
...AElf.Kernel.BlockPruning/BlockPruningAElfModule.cs	100.00% <100.00%> (ø)
...rc/AElf.Kernel.BlockPruning/BlockPruningOptions.cs	100.00% <100.00%> (ø)
...nel.BlockPruning/Domain/BlockPruningInfoManager.cs	100.00% <100.00%> (ø)
...Elf.Kernel.Core/Blockchain/Domain/IBlockManager.cs	100.00% <ø> (ø)
...Elf.Kernel.Core/Blockchain/Domain/IChainManager.cs	100.00% <ø> (ø)
...ore/Blockchain/Domain/ITransactionResultManager.cs	100.00% <ø> (ø)
src/AElf.Kernel/KernelAElfModule.cs	100.00% <ø> (ø)
...ckPruning/NewIrreversibleBlockFoundEventHandler.cs	91.66% <91.66%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eanzhao]

There is also a protocol-level compatibility issue when the requester's PreviousBlockHash has already been pruned on the serving node.

Once the header for firstHash is gone, GetBlockHashesAsync() returns an empty list immediately. On its own that is fine, but on the download side DownloadBlockCount == 0 is treated as "job finished" and the sync job is removed. In other words, a lagging node talking only to pruning peers can silently stop the download attempt instead of learning that this peer no longer has the requested historical range.

That makes the interaction look like a successful empty response rather than "history unavailable". I think the sync protocol needs a distinguishable outcome here, or a fallback path, otherwise long-offline nodes can get stuck depending on which peers they hit.

[eanzhao]

I think there is a correctness issue in the historical sync path after pruning.

BlockPruningService intentionally keeps the height-to-hash index but removes the corresponding historical BlockHeader / ChainBlockLink entries for pruned heights. The problem is that GetBlocksWithTransactionsAsync() still goes through GetBlocksInBestChainBranchAsync() -> GetBlockHashesAsync(), and that traversal still assumes those historical links exist.

In particular, if a fresh peer asks for blocks starting from genesis after pruning has already removed height 2/3/... data, GetBlockHashesAsync() can resolve first.Height, compute a target height, and then fail when it tries to walk back through a pruned ChainBlockLink before the later TakeWhile(block != null) safeguard in BlockchainServiceExtensions is reached. That turns a normal block request into an exception in the gRPC request path instead of a clean partial response.

So a pruning node can become unable to serve historical sync from genesis/new peers. I think this path needs an explicit "history pruned" behavior, or a traversal that stops cleanly once historical links are missing, not just null filtering at the very end.