Scan blocks with sapling keys and write the results to the database

[teor2345]

Motivation

This PR scans the blockchain and adds the scanner results to the scanner database.

Close #8021

I think it might also
close #7953
but @upbqdn feel free to replace that code with your PR, and re-open that ticket if it's not finished.

PR Author Checklist

Check before marking the PR as ready for review:

• Will the PR name make sense to users?
• Does the PR have a priority label?
• Have you added or updated tests?
• Is the documentation up to date?

For significant changes:

• Is there a summary in the CHANGELOG?
• Can these changes be split into multiple PRs?

If a checkbox isn't relevant to the PR, mark it as done.

The changelog summary for 1.5.0 already talks about scanning.

Complex Code or Requirements

I tried scanning with all the keys to make sure it would work, but we only really need to scan with the full viewing key. I couldn't find the encoding for individual viewing keys, so I left that until later.

There's also a bunch of spawn_blocking() calls in here.

Solution

Changes:

• Parse keys once at the start of the scan
  • Create a function that parses a key into a list of keys
  • Take a list of keys from the same key in the scanner for now
• Pass a ChainTipChange to the scanner function, this turned out to be mostly useless but it's good for progress
• Get a block from the state instead of the tip height
• Use a dummy sapling tree size
• Scan each block and add the results to storage
  • Convert a scanned block to a sapling result

Fixes:

• Fix availability of tokio::time in scanner
• Make it easier to pass keys and blocks to conversion functions
• Increase scanner wait times
• Don't log secret keys, only log every 100,000 blocks
• Move blocking tasks into spawn_blocking()

Testing

• Update the acceptance test

I manually tested this, getting it in CI is ticket #8037

Review

@oxarbitrage might want to review the scanner bits, and @upbqdn the block/state bits?

Reviewer Checklist

Check before approving the PR:

• Does the PR scope match the ticket?
• Are there enough tests to make sure it works? Do the tests cover the PR motivation?
• Are all the PR blockers dealt with?
  PR blockers can be dealt with in new tickets or PRs.

And check the PR Author checklist is complete.

Follow Up Work

#8022 then lots of testing:

• test(scan): Scan blocks containing ZECpages transactions with the ZECpages shielded key #7813
• Run Zebra's unit tests with the scanner enabled #8037
• Round-trip tests for the database formats

[teor2345]

Seems to work in my manual tests, and quickly too:

2023-12-01T04:57:54.983238Z INFO {zebrad="850bd6a" net="Main"}: zebra_scan::scan: Scanning the blockchain: now at block Height(600000), current tip Some((Height(2315746), block::Hash("00000000017abab20936b148ac1ed54a38cb87019f7ac489baeab2db256ea59e")))
2023-12-01T04:57:54.983251Z INFO {zebrad="850bd6a" net="Main"}: zebra_scan::scan: Scanning the blockchain for key 0, started at block Height(419200)

This is only running on one core, and doing each key twice (dfvk and ivks).

[oxarbitrage]

utACK. Looks really good to me, i left a few questions and optionals.