Update completion for persistent mon events w/ fwd event

If persistent_monitor_events is enabled, for forwarded HTLC claims there is no
need to block the outbound edge's RAA monitor update until the preimage makes
it into the inbound edge -- the outbound edge's preimage monitor event is
persistent and will keep being returned to us until the inbound edge gets the
preimage, instead.

Therefore, clean up the claim flow when persistent monitor events is enabled to
omit any usage of/reference to RAA monitor update blocking actions.

Author: valentinewallace

lightning/src/ln/channelmanager.rs

@@ -1512,6 +1512,17 @@ pub(crate) enum MonitorUpdateCompletionAction {
 		/// action is handled.
 		monitor_event_source: Option<MonitorEventSource>,
 	},
+	/// Indicates an [`events::Event`] should be surfaced to the user once the associated
+	/// [`ChannelMonitorUpdate`] has been durably persisted.
+	///
+	/// This is used when `persistent_monitor_events` is enabled for forwarded payment claims.
+	/// Unlike [`Self::EmitEventOptionAndFreeOtherChannel`], this variant does not carry any
+	/// channel-unblocking information because persistent monitor events never add
+	/// [`RAAMonitorUpdateBlockingAction::ForwardedPaymentInboundClaim`] blockers.
+	EmitEventAndAckMonitorEvent {
+		event: events::Event,
+		monitor_event_source: Option<MonitorEventSource>,
+	},
 	/// Indicates that one or more [`MonitorEvent`]s should be acknowledged via
 	/// [`chain::Watch::ack_monitor_event`] once the associated [`ChannelMonitorUpdate`] has been
 	/// durably persisted.
@@ -1542,6 +1553,10 @@ impl_writeable_tlv_based_enum_upgradable!(MonitorUpdateCompletionAction,
 	(3, AckMonitorEvents) => {
 		(0, monitor_events_to_ack, required_vec),
 	},
+	(4, EmitEventAndAckMonitorEvent) => {
+		(0, event, upgradable_required),
+		(1, monitor_event_source, option),
+	},
 );
 
 /// Result of attempting to resume a channel after a monitor update completes while locks are held.
@@ -9798,20 +9813,48 @@ impl<
 					)
 				} else {
 					let event = make_payment_forwarded_event(htlc_claim_value_msat);
-					if let Some(ref payment_forwarded) = event {
-						debug_assert!(matches!(
-							payment_forwarded,
-							&events::Event::PaymentForwarded { .. }
-						));
+					if self.persistent_monitor_events {
+						match (event, monitor_event_source) {
+							// Typically monitor_event_source is None here. The usual flow is: receive
+							// update_fulfill_htlc from outbound edge peer, call claim_funds with
+							// monitor_event_source = None, generate event here. Then, preimage gets into
+							// outbound edge monitor, get a preimage monitor event, call claim_funds again and
+							// hit the duplicate claim flow above. However, in the case that the ChannelManager
+							// is outdated and we got here after restart from an un-acked preimage monitor event,
+							// we can end up here with monitor event source = Some.
+							(Some(ev), mes) => (
+								Some(MonitorUpdateCompletionAction::EmitEventAndAckMonitorEvent {
+									event: ev,
+									monitor_event_source: mes,
+								}),
+								None,
+							),
+							(None, Some(mes)) => (
+								Some(MonitorUpdateCompletionAction::AckMonitorEvents {
+									monitor_events_to_ack: vec![mes],
+								}),
+								None,
+							),
+							(None, None) => (None, None),
+						}
+					} else {
+						if let Some(ref payment_forwarded) = event {
+							debug_assert!(matches!(
+								payment_forwarded,
+								&events::Event::PaymentForwarded { .. }
+							));
+						}
+						(
+							Some(
+								MonitorUpdateCompletionAction::EmitEventOptionAndFreeOtherChannel {
+									event,
+									downstream_counterparty_and_funding_outpoint: chan_to_release,
+									monitor_event_source,
+								},
+							),
+							None,
+						)
 					}
-					(
-						Some(MonitorUpdateCompletionAction::EmitEventOptionAndFreeOtherChannel {
-							event,
-							downstream_counterparty_and_funding_outpoint: chan_to_release,
-							monitor_event_source,
-						}),
-						None,
-					)
 				}
 			},
 		);
@@ -10601,6 +10644,15 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
 						Some(blocking_action),
 					);
 				},
+				MonitorUpdateCompletionAction::EmitEventAndAckMonitorEvent {
+					event,
+					monitor_event_source,
+				} => {
+					if let Some(source) = monitor_event_source {
+						self.chain_monitor.ack_monitor_event(source);
+					}
+					self.pending_events.lock().unwrap().push_back((event, None));
+				},
 				MonitorUpdateCompletionAction::AckMonitorEvents { monitor_events_to_ack } => {
 					for source in monitor_events_to_ack {
 						self.chain_monitor.ack_monitor_event(source);