Don't prune pending_requests in persist

Previously, we would also prune any pending `GetInfo` or expired `Buy`
requests before we `persist`. This could have lead to races where we
drop a pending request and even remove the peer when calling `persist`.

Here, we simply split the pruning logic for the `pending_requests` and
expired JIT channel state, and only prune the latter before persisting.
This generally makes sense, as `pending_requests` isn't currently
persisted, so there is no need to prune before repersisting.

Both are however still pruned on peer disconnection.

Backport of 5f8c54a

Author: tnull

lightning-liquidity/src/lsps2/service.rs

@@ -619,7 +619,7 @@ impl PeerState {
 		self.needs_persist |= true;
 	}
 
-	fn prune_expired_request_state(&mut self) {
+	fn prune_pending_requests(&mut self) {
 		self.pending_requests.retain(|_, entry| {
 			match entry {
 				LSPS2Request::GetInfo(_) => false,
@@ -629,7 +629,9 @@ impl PeerState {
 				},
 			}
 		});
+	}
 
+	fn prune_expired_request_state(&mut self) {
 		self.outbound_channels_by_intercept_scid.retain(|intercept_scid, entry| {
 			if entry.is_prunable() {
 				// We abort the flow, and prune any data kept.
@@ -1871,6 +1873,7 @@ where
 			let mut peer_state_lock = inner_state_lock.lock().unwrap();
 			// We clean up the peer state, but leave removing the peer entry to the prune logic in
 			// `persist` which removes it from the store.
+			peer_state_lock.prune_pending_requests();
 			peer_state_lock.prune_expired_request_state();
 		}
 	}