Add an immediately-freeing MonitorUpdateCompletionAction.

When `MonitorUpdateCompletionAction`s were added, we didn't
consider the case of a duplicate claim during normal HTLC
processing (as the handling only had an `if let` rather than a
`match`, which made the branch easy to miss). This can lead to a
channel freezing indefinitely if an HTLC is claimed (without a
`commitment_signed`), the peer disconnects, and then the HTLC is
claimed again, leading to a never-completing
`MonitorUpdateCompletionAction`.

The fix is simple - if we get back an
`UpdateFulfillCommitFetch::DuplicateClaim` when claiming from the
inbound edge, immediately unlock the outbound edge channel with a
new `MonitorUpdateCompletionAction::FreeOtherChannelImmediately`.

Here we add the new variant, which we start generating in the next
commit.

Author: TheBlueMatt

lightning/src/ln/channelmanager.rs

@@ -615,10 +615,28 @@ pub(crate) enum MonitorUpdateCompletionAction {
 		event: events::Event,
 		downstream_counterparty_and_funding_outpoint: Option<(PublicKey, OutPoint, RAAMonitorUpdateBlockingAction)>,
 	},
+	/// Indicates we should probably resume the operation of another channel.
+	///
+	/// This is usually generated when we've forwarded an HTLC and want to block the outbound edge
+	/// from completing a monitor update which removes the payment preimage until the inbound edge
+	/// completes a monitor update containing the payment preimage. However, we use this variant
+	/// instead of [`Self::EmitEventAndFreeOtherChannel`] when we discover that the claim was in
+	/// fact duplicative and we simply want to resume the outbound edge channel immediately.
+	///
+	/// This variant should thus never be written to disk, as it is processed inline rather than
+	/// stored for later processing.
+	FreeOtherChannelImmediately {
+		downstream_counterparty_and_funding_outpoint: (PublicKey, OutPoint, RAAMonitorUpdateBlockingAction),
+	},
 }
 
 impl_writeable_tlv_based_enum_upgradable!(MonitorUpdateCompletionAction,
 	(0, PaymentClaimed) => { (0, payment_hash, required) },
+	// Note that FreeOtherChannelImmediately should never be written - we were supposed to free
+	// *immediately*. However, for simplicity we implement read/write here.
+	(1, FreeOtherChannelImmediately) => {
+		(0, downstream_counterparty_and_funding_outpoint, required),
+	},
 	(2, EmitEventAndFreeOtherChannel) => {
 		(0, event, upgradable_required),
 		// LDK prior to 0.0.116 did not have this field as the monitor update application order was
@@ -5585,6 +5603,12 @@ where
 						self.handle_monitor_update_release(node_id, funding_outpoint, Some(blocker));
 					}
 				},
+				MonitorUpdateCompletionAction::FreeOtherChannelImmediately {
+					downstream_counterparty_and_funding_outpoint
+				} => {
+					let (node_id, funding_outpoint, blocker) = downstream_counterparty_and_funding_outpoint;
+					self.handle_monitor_update_release(node_id, funding_outpoint, Some(blocker));
+				},
 			}
 		}
 	}
@@ -9987,6 +10011,9 @@ where
 								// anymore.
 							}
 						}
+						if let MonitorUpdateCompletionAction::FreeOtherChannelImmediately { .. } = action {
+							debug_assert!(false, "Non-event-generating channel freeing should not appear in our queue");
+						}
 					}
 				}
 				peer_state.lock().unwrap().monitor_update_blocked_actions = monitor_update_blocked_actions;