zcash_client_backend: Avoid leaking subtree affinity for found notes

[nuttycom]

At present, when performing out-of-order scanning, finding a note results in a FoundNote priority range being inserted into the scan queue. This priority range likely has a different size than the default scan chunk size, and as a consequence the light wallet server can distinguish which subtrees have notes belonging to the wallet. Up until now, we haven't worried about this too much, because the memo retrieval has leaked much more information about which transactions the wallet is interested in. However, with transaction retrieval moving to requests performed over Tor, this now becomes an important metadata leak to the lightwalletd server.

A good solution to this is to make scan retrieval ranges uniformly sized and uniformly distributed over the shards, and scanning should also probably be performed in random order. When this change is made, we should also verify that the scan ranges introduced by zcash_client_sqlite::wallet::commitment_tree::check_witnesses (see #1709) are not distinguishable from ordinary scanning operations.