Handle mon update completion actions even with update(s) is blocked

[TheBlueMatt]

If we complete a ChannelMonitorUpdate persistence but there are blocked ChannelMonitorUpdates in the channel, we'll skip all the post-monitor-update logic entirely. While its correct that we can't resume the channel (as it expected the monitor updates it generated to complete, even if they ended up blocked), the post-update actions are a channelmanager.rs concept - they cannot be tied to blocked updates because channelmanager.rs doesn't even see blocked updates.

This can lead to a channel getting stuck waiting on itself. In a production environment, an LDK user saw a case where:
(a) an MPP payment was received over several channels, let's call
them A + B.
(b) channel B got into AwaitingRAA due to unrelated operations,
(c) the MPP payment was claimed, with async monitor updating,
(d) the revoke_and_ack we were waiting on was delivered, but the
resulting ChannelMonitorUpdate was blocked due to the
pending claim having inserted an RAA-blocking action,
(e) the preimage ChannelMonitorUpdate generated for channel B
completed persistence, which did nothing due to the blocked
ChannelMonitorUpdate.
(f) the Event::PaymentClaimed event was handled but it, too,
failed to unblock the channel.

Instead, here, we simply process post-update actions when an update completes, even if there are pending blocked updates. We do not fully unblock the channel, of course.

[ldk-reviews-bot]

👋 Thanks for assigning @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[codecov]

Codecov Report

❌ Patch coverage is 94.82759% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.30%. Comparing base (6d9c676) to head (8f4a4d2).
⚠️ Report is 24 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/functional_test_utils.rs	84.61%	1 Missing and 5 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4236 +/- ##
==========================================
- Coverage 89.32% 89.30% -0.03% 
==========================================
Files 180 180 Lines 138641 138803 +162 Branches 138641 138803 +162 ==========================================
+ Hits 123844 123955 +111 - Misses 12174 12223 +49 - Partials 2623 2625 +2 

Flag	Coverage Δ
fuzzing	35.02% <2.32%> (-0.96%)	⬇️
tests	88.66% <94.82%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[wpaulino]

LGTM

[ldk-reviews-bot]

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

[valentinewallace]

LGTM

[valentinewallace]

nit: s/paymnt_hash_1/payment_hash_1

[TheBlueMatt]

Does it really impact readability? Was trying to avoid a rustfmt.

[valentinewallace]

Oh, it looks like a typo. Would prefer pmt_hash_1. Non-blocking though.

[TheBlueMatt]

Corrected the now-spurious documentation on the post-update macro -

$ git diff-tree -U2 eb5492f5cf 8f4a4d239d
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index cd063bbe33..11923a20b7 100644
--- a/lightning/src/ln/channelmanager.rs+++ b/lightning/src/ln/channelmanager.rs@@ -3356,6 +3356,5 @@ macro_rules! emit_initial_channel_ready_event {
/// `handle_new_monitor_update` or [`ChannelManager::channel_monitor_updated`] to call it for you.
///
-/// Requires that `$chan.blocked_monitor_updates_pending() == 0` and the in-flight monitor update-/// set for this channel is empty!+/// Requires that the in-flight monitor update set for this channel is empty!
macro_rules! handle_monitor_update_completion {
($self: ident, $peer_state_lock: expr, $peer_state: expr, $per_peer_state_lock: expr, $chan: expr) => {{

[TheBlueMatt]

Backported in #4254