Block Range Scanner in Historic and Latest Events Modes Should Expose an Ack-Channel To Calculate the Next Block Range

NOTE: the issues solved by this feature are very unlikely, and even then they would affect only those apps where max_block_range is smaller than the number of non-finalized blocks on the blockchain; the smaller the max_block_range, the more the likely that the issue is to happen.

Currently these two modes run "too fast", meaning the block range scanner finishes it's operation in a matter of milliseconds, while the consumer may take longer to process each block range in turn. This means that when BRS emits a block range it's valid, but by the time the consumer processes it, a reorg could've occurred, which would not be detected, as BRS stops working once it emits all of the block ranges.

Introducing an acknowledgement channel would allow the consumer to give a go-ahead to the BRS to calculate only the next block range, keeping BRS alive and detecting reorgs Just-in-Time.

This would allow us to uncomment these two tests:

• historical_emits_correction_range_when_reorg_below_end
• historical_emits_correction_range_when_end_num_reorgs

Start with the Block Range Scanner implementation and its Historic and Latest Events modes, then inspect the commented cases in tests/block_range_scanner.rs. Trace how the scanner emits ranges and how the consumer can acknowledge them. Done means an acknowledgement channel advances range calculation and the two named reorg tests can be uncommented and pass.