Proposal: Deep Rescan

[pinheadmz]

How wallet rescan works:

1. rollback to specified height
   • this means un-confirming all TX history from tip backwards to target height
2. rewind and play blockchain back into wallet, re-confirming TXs from step 1 and potentially inserting (and then immediately confirming) new TXs that were not already in the wallet.

So what rescan does NOT do is start from a completely empty state with a mnemonic seed and rebuild TX history from scratch. That is typically called a `"recovery".

We've had a few critical txdb issues recently that result in assertion errors:

#454

#464

Users have to recover (not rescan) their wallet because of the corrupt balance. To make matters worse, the fact that a corrupted wallet still lives in the DB (even if its not used anymore) means these assertion errors can not be avoided without completely re-initializing the entire db.

There is a method to remove wallets from the db but it is not exposed in the API for obvious reasons, and is not allowed to remove the primary wallet.

SO -- Should there be a new wallet method called deep rescan or an extra argument to rescan that does a deep clean of the wallet before replaying the blockchain?

The benefit to the user would be the ability to fix corrupted state without creating a brand new walletDB. The DB would stay in place and the wallet name would stay in place.

[pinheadmz]

Another benefit of this over a wallet import-from-seed is that we should be able to keep the database of address hashes and serialized account metadata, so the lookahead issue is mitigated. We would only reset balance and tx history. I think also it should be required that the deep rescan start from genesis, (a) to reduce user options since this is a bit of a nuclear bomb and (b) to ensure that we don't accidentally recover a REVEAL without first recovering the BID, etc.