Always process `ChannelMonitorUpdate`s asynchronously
authorMatt Corallo <git@bluematt.me>
Wed, 11 Jan 2023 21:37:57 +0000 (21:37 +0000)
committerMatt Corallo <git@bluematt.me>
Wed, 22 Feb 2023 17:34:46 +0000 (17:34 +0000)
commit4e002dcf5c97f506cf8e79e9fab02d71808cae5f
treecba5cd236b7fdb9239b5b5af82e11cfe7b3ad5c2
parent46c6fb7f91b180fcae8358c82228008fa4eab2c4
Always process `ChannelMonitorUpdate`s asynchronously

We currently have two codepaths on most channel update functions -
most methods return a set of messages to send a peer iff the
`ChannelMonitorUpdate` succeeds, but if it does not we push the
messages back into the `Channel` and then pull them back out when
the `ChannelMonitorUpdate` completes and send them then. This adds
a substantial amount of complexity in very critical codepaths.

Instead, here we swap all our channel update codepaths to
immediately set the channel-update-required flag and only return a
`ChannelMonitorUpdate` to the `ChannelManager`. Internally in the
`Channel` we store a queue of `ChannelMonitorUpdate`s, which will
become critical in future work to surface pending
`ChannelMonitorUpdate`s to users at startup so they can complete.

This leaves some redundant work in `Channel` to be cleaned up
later. Specifically, we still generate the messages which we will
now ignore and regenerate later.

This commit updates the `ChannelMonitorUpdate` pipeline across all
the places we generate them.
lightning/src/chain/chainmonitor.rs
lightning/src/ln/chanmon_update_fail_tests.rs
lightning/src/ln/channel.rs
lightning/src/ln/channelmanager.rs
lightning/src/ln/functional_tests.rs