A redesign of the scanning task

[upbqdn]

New main scanning task

I tried coming up with the following verbal description of a new scanning task. Upon starting Zebra, the new main scanning task will:

1. Get the current tip and read the database with scanning results.

2. Create sets of keys with equal last scanned height.

3. Store these sets in a map, where a height identifies each set of scanning
   keys. The height for each set essentially represents a "birth height" of
   the whole set, meaning that the interval between this height and the tip
   needs to be scanned. The other interval between genesis and the height of
   the set has its results in the database. All sets are labeled as
   "unlocked" when created.

4. If there are unlocked sets with a height less than, say, ten from the tip,
   create a new scanning task for this set and label it as "locked," meaning
   that keys cannot be added but can be removed from the set. The new tasks
   will write the results to the database on their own. Upon finishing, the
   task will return the last scanned height to the main task, and the main
   task will use it to update the height that identifies the set in the map
   and "unlock" the set. The locks can be just labels since only the main
   scanning task will operate on the sets.

5. Merge all unlocked sets having the same height.

6. Check if there are new keys coming from the RegisterKeys gRPC. If there
   are, then:

   1. If there's an unlocked set with a height matching the key's birth
      height, add the key to the set.
   2. If there's a locked set with a height matching the key's birth height,
      create a new set with height = (birth_height - 1). We can't add
      keys to locked sets because these sets have a scanning task running for
      them. Creating a new set with a height one less than the key's birth
      height is a small workaround for having multiple sets with the same
      height.
   3. If there's no set with a height matching the key's birth height, create
      a new one.

7. Sleep.

8. Wake up on:

   1. a finished scanning task,
   2. tip change (here we could handle rollbacks),
   3. gRPC:
      1. RegisterKeys,
      2. DeleteKeys,

   and jump to step 4.

Note that:

1. Over time, the map described above should converge to a state with only one
   set identified by a height equal to the current tip.
2. The convergence described above should happen quickly, and the scanning task
   should keep resubmitting only one set of keys for scanning for each new tip
   in a regular Zebra operation. The convergence should happen quickly because
   most tasks will have the same end height, equal to the tip at the time of
   creating the scanning task. This should hold if Zebra is not restarted when
   there are multiple tasks running, which is expected.

This design should:

1. Handle restarts well since it doesn't seem to have any restart-related
   edge cases. If there's a restart, the main scanning task reads the scanning
   state from the database and recreates the map.
2. Fit the other scanning API in zcash-client-backend that supports batching.

Instead of having the sets in a map, a simple vector might suffice. The sets
would be extended at least with a height and the locking label.