Support during-sync operation

[TheBlueMatt]

We should have a mode where a ChannelManager will only take "safe" actions which can occur while the chain is being synchronized in the background (ie we are guaranteed that we are behind the current tip, but will be in sync soon). When we do this we should also support syncing only to common tip(s) in the block-sync crate, see https://github.com/rust-bitcoin/rust-lightning/pull/791#discussion_r576364349.

[ariard]

I think the following actions can be labeld as "safe":

• "read" : e.g list_channels, state might not be accurate but won't be change, so we can return data to the consumer flagging them as in-sync, so not 100% reliable
• "gossips"-related: timer_chan_freshness_every_min,
• balance-decreasing : sending payment N is safe, if any onchain commitment N-i has already been confirmed with different balances, the double-spend will be swallowed by our counterparty
• channel opening : if we're initiator we might propose an opening with a no-more-available UTXO, worst-case scenario we broadcast an invalid funding transaction

Balance-increasing or closing are unsafe as a state less favorable to us might have been already committed onchain.

In theory we could make those "dangerous" operations valid if we lower our trust model by relying on some headers-verified at-tip assumevalid-UTXO, once those are available on the base layer. If you don't care about verifying gossips traffic and assuming you don't have channel close, you might bypass completely sync for mobile. The hard challenge is conserving privacy of your utxos towards semi-trusted assumevalid/BIP157 servers...

[TheBlueMatt]

Jeff notes in the above references in 808 that we should try to enforce this via an API refactor if possible, eg wrapping ChannelManager in a ChannelManagerSyncing object during deserialization and only allowing access to a subset of the API until the user informs us they're done.