Ack monitor event when inbound edge is closed

Currently, the resolution of HTLCs (and decisions on when HTLCs can be
forwarded) is the responsibility of Channel objects (a part of ChannelManager)
until the channel is closed, and then the ChannelMonitor thereafter. This leads
to some complexity around race conditions for HTLCs right around channel
closure. Additionally, there is lots of complexity reconstructing the state of
all HTLCs in the ChannelManager deserialization/loading logic.

Instead, we want to do all resolution in ChannelMonitors (in response to
ChannelMonitorUpdates) and pass them back to ChannelManager in the form of
MonitorEvents (similar to how HTLCs are resolved after channels are closed). In
order to have reliable resolution, we'll need to keep MonitorEvents around in
the ChannelMonitor until the ChannelManager has finished processing them. This
will simplify things - on restart instead of examining the set of HTLCs in
monitors we can simply replay all the pending MonitorEvents.

Here we build on recent commits by ACK'ing monitor events for forward failures
if try to fail backwards and discover the inbound edge is closed. If that's the
case, there's nothing for us to do as the HTLC will be resolved via timeout
by the inbound edge counterparty.

Author: valentinewallace

lightning/src/ln/channelmanager.rs

@@ -7971,11 +7971,15 @@ impl<
 						continue;
 					}
 				},
-				HTLCForwardInfo::FailHTLC { .. } | HTLCForwardInfo::FailMalformedHTLC { .. } => {
+				HTLCForwardInfo::FailHTLC { monitor_event_source, .. }
+				| HTLCForwardInfo::FailMalformedHTLC { monitor_event_source, .. } => {
 					// Channel went away before we could fail it. This implies
 					// the channel is now on chain and our counterparty is
 					// trying to broadcast the HTLC-Timeout, but that's their
 					// problem, not ours.
+					if let Some(source) = monitor_event_source {
+						self.chain_monitor.ack_monitor_event(source);
+					}
 				},
 			}
 		}