Rebuild pending payments list before replaying pending claims/fails

On `ChannelManager` reload we rebuild the pending outbound payments
list by looking for any missing payments in `ChannelMonitor`s.
However, in the same loop over `ChannelMonitor`s, we also re-claim
any pending payments which we see we have a payment preimage for.

In theory this can lead to a pending payment getting re-added and
re-claimed multiple times if it was sent as an MPP payment across
multiple channels. Worse, if it was claimed on one channel and
failed on another, in theory we could get both a `PaymentFailed`
and a `PaymentClaimed` event on startup for the same payment.

Author: TheBlueMatt

lightning/src/ln/channelmanager.rs

@@ -16297,6 +16297,10 @@ where
 			// payments which are still in-flight via their on-chain state.
 			// We only rebuild the pending payments map if we were most recently serialized by
 			// 0.0.102+
+			//
+			// First we rebuild the pending payments, and only once we do so we go through and
+			// re-claim and re-fail pending payments. This avoids edge-cases around MPP payments
+			// resulting in redundant actions.
 			for (channel_id, monitor) in args.channel_monitors.iter() {
 				let mut is_channel_closed = false;
 				let counterparty_node_id = monitor.get_counterparty_node_id();
@@ -16335,6 +16339,18 @@ where
 							);
 						}
 					}
+				}
+			}
+			for (channel_id, monitor) in args.channel_monitors.iter() {
+				let mut is_channel_closed = false;
+				let counterparty_node_id = monitor.get_counterparty_node_id();
+				if let Some(peer_state_mtx) = per_peer_state.get(&counterparty_node_id) {
+					let mut peer_state_lock = peer_state_mtx.lock().unwrap();
+					let peer_state = &mut *peer_state_lock;
+					is_channel_closed = !peer_state.channel_by_id.contains_key(channel_id);
+				}
+
+				if is_channel_closed {
 					for (htlc_source, (htlc, preimage_opt)) in
 						monitor.get_all_current_outbound_htlcs()
 					{