feat(zcash_client_sqlite): Retain stable witness data during truncation

[nullcopy]

There are scenarios where a the wallet may need to rescan the chain, even though it has account(s) with known spendable notes.

For example, consider a wallet which already has one (account A) and imports a new account (account B). The wallet will need to re-scan from the birthday height of B to discover its notes/balances. Currently, the truncation process applies to both accounts, resulting in the witness data corresponding to account A's notes being forgotten until it is regenerated during the re-scan. Ideally, account A's notes would still be spendable (e.g. still have the witness data) even during the re-scan, so that the user can still use A while re-scanning for B.

Possible solution: Exclude 'stable' witness data from truncation
Essentially, add a flag to mark notes as 'stable' once they've been confirmed up to the pruning depth. Then, modify pruning to exclude removal of witness data corresponding to those 'stable' notes.

[linear]

COR-1192

[nuttycom]

It's not the case that account A's notes are forgotten; we never delete information about a wallet's notes.

[nuttycom]

Modify truncation to be account specific, so that truncating the state of one account does not truncate the state of another

The problem is that there isn't account-specific note commitment tree state; it's a single tree, containing the nodes required to construct witnesses for any note in any account. While it would be possible to store per-account scan queue information, managing multiple scan queues also doesn't make sense; a given block only needs to be (re)-scanned once. Now, admittedly it would be nice to be able to partition and avoid re-scanning with keys that have already been used to scan a particular block, but this is IMO a microoptimization; the complexity of maintaining per-account scan queues far outweighs the benefit one would gain.

[nullcopy]

It's not the case that account A's notes are forgotten; we never delete information about a wallet's notes.

Oops, I misspoke. I meant to say the witness data necessary to spend the notes is forgotten. Not the notes themselves.

The problem is that there isn't account-specific note commitment tree state; it's a single tree

Right, I forgot about this... This alone makes the 'Truncate by account' idea DOA. I'll remove that from the issue to minimize confusion