Refactor ScanTask in zebra-scan

[arya2]

Motivation

The scan task in zebra-scan is could be simplified and more maintainable if it were refactored, possibly into a new tower service or by adding some of its logic to the existing ScanService.

This would make it easier to:

• Implement efficient batch scanning
• Register keys immediately (it's currently only checking for new registered keys before scanning a block in the root scan task, but not while it's scanning a block)
• Subscribe to results for a block height while it's still being scanned (so that simultaneous Results and SubscribeResults requests will catch any results for a given key without extra logic)

Possible Design

A design meeting could be worthwhile to discuss possible designs. We may want to consider the Downloads service in the inbound service and/or the QueuedBlocks struct in the state service.

Example:

We could replace the scan_task field on the ScanService with scan_tasks

struct ScanTasks {
    /// Watch channel of senders for subscribed clients
    result_senders: tokio::sync::watch::Sender<HashMap<String, Sender<()>>>,

    /// Scan tasks by id
    tasks_by_id: HashMap<ScanTaskId, ScanTask>,

    /// tasks scanning transactions for a given key
    by_key: HashMap<String, Vec<ScanTaskId>>,

    /// tasks by the next block height that they will scan
    by_height: BTreeMap<Height, ScanTaskId>,
}

[arya2]

We may want to do #7934 in the same PR as this one to avoid changing a lot of the scan task twice, we can do #7927 first to prepare for #7934.

[upbqdn]

There's a discussion about the new design in #8271.

[mpguerra]

@arya2 is this still relevant in light of #8581 ?

[arya2]

@arya2 is this still relevant in light of #8581 ?

Yeah, it's not affected by #8581, though it doesn't seem like a priority right now.