wallet: skip rescan if address batch is empty

[benthecarman]

No description provided.

[guggero]

This change sounds reasonable to me, though I'm not sure if there's a reason for allowing empty rescans. @Roasbeef, do you have any insights here?

[losh11]

Any update?

[Roasbeef]

Should have a PR to lnd to update the dep to see if anything breaks itest wise. I think only reason to do the rescan is that we get an update that the rescan is finished even if it was empty? So maybe we want to send the finished notification asap if we get an empty batch.

[litch]

We're a few days into debugging some performance issues that this would resolve absolutely.

What we're finding is that when running starting up an LND node against mutinynet, the initial chain rescan (for the empty state of the wallet) picks a time ~5k blocks in the past.

 Locating suitable block for birthday 2024-04-15 23:13:16 +0000 UTC between blocks 0-1013946
2024-04-17 23:13:20.185 [DBG] LNWL: Checking candidate block: height=506973, hash=000000c080f3d1f9cad4f523469a529a4621e3fb9c3b1e765e462730125c53da, timestamp=2023-10-19 02:04:47 +0000 UTC
...
2024-04-17 23:13:21.224 [DBG] LNWL: Found birthday block: height=1008499, hash=000000fe0d28f5152dc961777e46edf861011d4643069ab9cc3165a750d7fbca, timestamp=2024-04-16 00:22:57 +0000 UTC
2024-04-17 23:13:21.513 [INF] LNWL: Started rescan from block 000000fe0d28f5152dc961777e46edf861011d4643069ab9cc3165a750d7fbca (height 1008499) for 0 addresses

It consistently picks a block ~5k in the past, and then does a rescan (for an empty wallet). Under most circumstances that we have found, this rescan takes an extremely long time (~50 minutes). We have found cases where it is faster than that, but it's pretty consistently slow under a range of conditions.

[Roasbeef]

@litch so the height estimation for a wallet's birthday is based on assumption about the block rate interval. If Mutinynet is mining blocks with a diff interval, or one that's variable, then the value will be incorrect.

With that said, this comment still stands: #824 (comment)

If you're running into this issue in production, do you want to take over this PR @litch?