`WatchedOutput::block_hash` is not persistent across restarts

[tnull]

In WatchedOutput::block_hash we return the "[f]irst block where the transaction output may have been spent."

However, we only set this Some when we initially process the parent transaction: https://github.com/lightningdevkit/rust-lightning/blob/1fdb052afc0a7200f31c806a2c3e0932f1914170/lightning/src/chain/chainmonitor.rs#L319 but not when re-registering after a restart: https://github.com/lightningdevkit/rust-lightning/blob/1fdb052afc0a7200f31c806a2c3e0932f1914170/lightning/src/chain/channelmonitor.rs#L1262

I may be wrong, but as far as I can tell even re-confirming the registered transactions after restart might not lead to restore the block_hash value as we may omit processing them again in ChanneMonitor::transactions_confirmed/block_connected.

While probably not a big deal, it's strange either way to have this field not persisted during restarts (and potentially never filled in again). I see two potential ways to improve this:

• Filling in the block hash value from Channel::funding_tx_confirmed_in in load_outputs_to_watch.
• Better document what users can expect from Filter, e.g., that they possibly need to do multiple sync roundtrips after restart to reach a steady state. (probably should be part of #1069)

[wpaulino]

So the use of WatchedOutput::block_hash here is to rescan the exact block (not all blocks going forward from that point, as a typical rescan would) which is producing the additional register_output requests. If we restart before doing said rescan, we'd lose the context and miss notifying the additional outputs as spent if they were also spent in the same block. The tricky part though is that there's no way in the API to communicate that the rescan was done and didn't find anything, such that we can keep WatchedOutput::block_hash as None and just continue watching for the spend at tip.