Matt Corallo 7fa499c188 Separate ChannelManager needing persistence from having events ... Currently, when a ChannelManager generates a notification for the background processor, any pending events are handled and the ChannelManager is always re-persisted. Many channel related messages don't actually change the channel state in a way that changes the persisted channel. For example, an `update_add_htlc` or `update_fail_htlc` message simply adds the change to a queue, changing the channel state when we receive a `commitment_signed` message. In these cases we shouldn't be re-persisting the ChannelManager as it hasn't changed (persisted) state at all. In anticipation of doing so in the next few commits, here we make the public API handle the two concepts (somewhat) separately. The notification still goes out via a single waker, however whether or not to persist is now handled via a separate atomic bool.		2023-09-12 19:06:34 +00:00
..
src	Separate ChannelManager needing persistence from having events	2023-09-12 19:06:34 +00:00
Cargo.toml	http => https	2023-07-23 08:58:41 +03:00