enhancement: optimized reorg handling by deferring checks to end of stream (historic)

[yug49]

Resolves #227

Description

This PR optimizes the historic/sync scanning modes by deferring reorg checks until after all block ranges have been streamed.

Changes

1. stream_historical_range in common.rs:

• Phase 1: Stream all finalized blocks without any reorg checks (unchanged)
• Phase 2: Stream all non-finalized block ranges without intermediate reorg checks
• After streaming the last range, check if the end block still exists (single reorg check)
• If a reorg is detected (BlockNotFound), send ReorgDetected notification and re-stream all non-finalized blocks
• Repeat until stable (end block exists or has become finalized)

2. handle_historical in block_range_scanner.rs:

• Removed ReorgHandler instantiation and parameter passing (no longer needed for historic mode)

3. sync_handler.rs:

• catchup_historical_blocks no longer requires reorg_handler parameter
• Reorg handling during sync's historical phase now uses the optimized approach

[LeoPatOZ]

Hi @yug49 thanks for the contribution.

Do you mind updating this PR (merging main) and using the new range_iterator for the looping logic

[yug49]

Hi @yug49 thanks for the contribution.

Do you mind updating this PR (merging main) and using the new range_iterator for the looping logic

Hello @LeoPatOZ
I have merged and updated it.

[LeoPatOZ]

Hey @yug49 sorry for the delayed response re this PR.

Looking a lot better - I had the idea of refactoring this and creating a historical_range_handler.rs similar to sync_handler.rs. I made a PR (which i closed given its a refactor of this one), where you can take some inspo.

The major difference is

1. Creating the historical handler
2. Splitting up this function into two / three smaller ones. I ended up having, stream_finalized_blocks, stream_non_finalized_blocks and check_reorg. I think it splits this flow nicely and makes the intention clearer

[yug49]

Hey @yug49 sorry for the delayed response re this PR.

Looking a lot better - I had the idea of refactoring this and creating a historical_range_handler.rs similar to sync_handler.rs. I made a PR (which i closed given its a refactor of this one), where you can take some inspo.

The major difference is

1. Creating the historical handler

2. Splitting up this function into two / three smaller ones. I ended up having, stream_finalized_blocks, stream_non_finalized_blocks and check_reorg. I think it splits this flow nicely and makes the intention clearer

No problem @LeoPatOZ
I will refactor it.

[yug49]

Hey @LeoPatOZ
I have refactored it, please review