[Wallet] Add set of unscanned-block-height-ranges to key metadata #9425

To assist querying keys in the wallet, the key metadata should keep track of what block height ranges it MAY not know the transactions for.

Upon a full-rescan: all keys should have their 'unscanned' ranges cleared.

Upon 'pruning' a set of translations in a wallet: all related keys in the wallet should be updated with the appropriate 'unscanned' ranges.

If upon opening a wallet the client cannot connect an appropriate hash and rescan (such as when changing wallets on a pruned node). All keys in the wallet should be set to include the unscanned range upto where then node keeps full-blocks (and can rescan from).

The ranges should be conservative so that the wallet can be quite confident that it knows about all the transactions that are not inside the unscanned ranges. The wallet may also know about transactions that are inside the unscanned ranges.

Note: Updated upon @sipa 's comments that the wallets already have implement many similar behaviour to what is described.

We're already doing most of this. Keys have a birth timestamp. The wallet contains the hashes of the top 10 blocks in the chain at flush time, plus exponentially further back ones (so: 1, 2, ..., 10, 11, 13, 17, 25, 41, 73, 137, 265, ... back). At startup, we find the latest common block between the new tip and those saved hashes, and automatically rescan from there. I don't know what pruning you're talking about - wallet transactions are never pruned.

@sipa thankyou for your informed prompt response, I'll update the issue accordingly.

On Wallet Pruning. This was mentioned on IRC as possible feature for the 500mb merchant wallets. So that old transactions may be removed from the wallet. (for performance reasons).

How is this issue different from #9409?

@MarcoFalke #9409 Heads in the same direction. Indeed this idea was inspired by reading the IRC discussion.

However, this proposes a particular feature where instead of querying a wallet for it 'pruned' state, instead you are querying a key if it has been associated with pruned transactions. Just a natural extension I suppose.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.