wallet: Fix off-by-one in addr discovery

[matheusd]

This fixes an off-by-one in sizing the backing array for cfilter data during address discovery.

During address discovery, the GetMainChainCFilters call to fetch cfilters from the DB uses an array sized by the caller to put the data. However, due to being an inclusive fetch, the call in the address finder is not correctly sized, missing one (i.e. the last) block.

This could cause an issue when the wallet had a single address used and that address was used on a transaction on the wallet's tip, causing the wallet to miss that address being used.

Required by #2318.

This was uncovered while debugging this test

[jrick]

nice find

[matthawkins90]

It seems like this is such a rare edge case. Am I correct in understanding that in order for this bug to occur:

• Wallet A would need to generate an address
• Wallet B would need to send it a tx
• Wallet A would be deleted
• The tx would be mined into the tip block
• Wallet A would be restored--syncing with the tip block, but prior to any other blocks being mined
• Wallet A would miss the transaction in the tip block?

And if any other blocks were mined, it would be fine?
I'm just trying to clarify for DJ how rare this situation might've been.
I'm also curious if, when more blocks are mined, if a rescan would've fixed this for users.

[matheusd]

Your example should trigger the issue, but a simpler one is just:

• Empty wallet generates an address
• Wallet is shutdown
• Some other wallet (or miner reward) is sent to the address and the tx is mined
• Wallet is restored from seed and misses the tx

A rescan would indeed fix the issue and having more blocks would also prevent the issue from being hit.

This is an issue that would likely only affect automated tests that have precise control over the entire situation (which is indeed how I found it).