Immediately unblock channels on duplicate claims

[TheBlueMatt]

When MonitorUpdateCompletionActions 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.

[tnull]

First high-level pass.

[codecov-commenter]

Codecov Report

Attention: 29 lines in your changes are missing coverage. Please review.

Comparison is base (6cafba9) 89.00% compared to head (5b71cd9) 89.63%.
Report is 22 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2661      +/-   ##
==========================================
+ Coverage   89.00%   89.63%   +0.63%     
==========================================
  Files         112      112              
  Lines       87207    91365    +4158     
  Branches    87207    91365    +4158     
==========================================
+ Hits        77619    81897    +4278     
+ Misses       7353     7231     -122     
- Partials     2235     2237       +2     

Files	Coverage Δ
lightning/src/ln/chanmon_update_fail_tests.rs	97.71% <98.38%> (+0.01%)	⬆️
lightning/src/ln/channelmanager.rs	86.13% <83.62%> (+4.55%)	⬆️

... and 20 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[valentinewallace]

Still going through a first pass

[valentinewallace]

Probably ready for a 2nd reviewer

[valentinewallace]

We can move this to where the event is generated below. Can we also stop gating this whole thing on if let Some(forwarded_htlc_value) .. or add a comment for why we're doing so?

[TheBlueMatt]

Yea, its fine cause we only have None when claiming from a(n old) monitor, which we dont have to restore, but I'll move it, good idea.

[valentinewallace]

Feel free to squash.

[TheBlueMatt]

Pushed a number of further changes so didn't squash yet.

[valentinewallace]

No real feedback, LGTM after a 2nd reviewer.

[TheBlueMatt]

Squashed with one additional assertion and a comment fix:

$ git diff-tree -U3 80792aab a6d4676c
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 217922ca5..b12fc3c86 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -5617,10 +5617,21 @@ where
 								// There should be a `BackgroundEvent` pending...
 								assert!(background_events.iter().any(|ev| {
 									match ev {
-										// to apply a monitor update that blocked channel,
+										// to apply a monitor update that blocked the claiming channel,
 										BackgroundEvent::MonitorUpdateRegeneratedOnStartup {
-											funding_txo, ..
-										} => *funding_txo == claiming_chan_funding_outpoint,
+											funding_txo, update, ..
+										} => {
+											if *funding_txo == claiming_chan_funding_outpoint {
+												assert!(update.updates.iter().any(|upd|
+													if let ChannelMonitorUpdateStep::PaymentPreimage {
+														payment_preimage: update_preimage
+													} = upd {
+														payment_preimage == *update_preimage
+													} else { false }
+												), "{:?}", update);
+												true
+											} else { false }
+										},
 										// or the channel we'd unblock is already closed,
 										BackgroundEvent::ClosedMonitorUpdateRegeneratedOnStartup((funding_txo, ..))
 											=> *funding_txo == next_channel_outpoint,
$ 

[tnull]

LGTM, feel free to squash.

[TheBlueMatt]

Squashed with a small wording tweak in the log:

$ git diff-tree -U1 5b71cd9a f47270e7
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index d66b6c478..1a4bdfbf6 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -6542,3 +6542,3 @@ where
 							log_trace!(self.logger,
-								"Holding the next revoke_and_ack from {} until the preimage is durably in the inbound edge's ChannelMonitor",
+								"Holding the next revoke_and_ack from {} until the preimage is durably persisted in the inbound edge's ChannelMonitor",
 								msg.channel_id);
@@ -10130,3 +10130,3 @@ where
 								log_trace!(args.logger,
-									"Holding the next revoke_and_ack from {} until the preimage is durably in the inbound edge's ChannelMonitor",
+									"Holding the next revoke_and_ack from {} until the preimage is durably persisted in the inbound edge's ChannelMonitor",
 									blocked_channel_outpoint.to_channel_id());
$