Avoid disconnecting all peers if user event processing is slow

In the sample client (and likely other downstream users), event
processing may block on slow operations (e.g. Bitcoin Core RPCs).
This should be fine, except that we consider this a case of
possible backgrounding and disconnect all of our peers when it
happens.

Instead, we here avoid considering event processing time in the
time between PeerManager events.

Author: TheBlueMatt

lightning-background-processor/src/lib.rs

@@ -209,8 +209,10 @@ impl BackgroundProcessor {
 			let mut last_ping_call = Instant::now();
 			loop {
 				peer_manager.process_events();
+				let user_ev_handle_start = Instant::now();
 				channel_manager.process_pending_events(&event_handler);
 				chain_monitor.process_pending_events(&event_handler);
+				let user_ev_handle_time = Instant::now() - user_ev_handle_start;
 				let updates_available =
 					channel_manager.await_persistable_update_timeout(Duration::from_millis(100));
 				if updates_available {
@@ -226,14 +228,19 @@ impl BackgroundProcessor {
 					channel_manager.timer_tick_occurred();
 					last_freshness_call = Instant::now();
 				}
-				if last_ping_call.elapsed().as_secs() > PING_TIMER * 2 {
+				if last_ping_call.elapsed().as_secs() - user_ev_handle_time > PING_TIMER * 2 {
 					// On various platforms, we may be starved of CPU cycles for several reasons.
 					// E.g. on iOS, if we've been in the background, we will be entirely paused.
 					// Similarly, if we're on a desktop platform and the device has been asleep, we
 					// may not get any cycles.
 					// In any case, if we've been entirely paused for more than double our ping
 					// timer, we should have disconnected all sockets by now (and they're probably
 					// dead anyway), so disconnect them by calling `timer_tick_occurred()` twice.
+					// Note that we have to take care to not get here just because user event
+					// processing was slow at the top of the loop. For example, the sample client
+					// may call Bitcoin Core RPCs during event handling, which very often takes
+					// more than a handful of seconds to complete, and shouldn't disconnect all our
+					// peers.
 					log_trace!(logger, "Awoke after more than double our ping timer, disconnecting peers.");
 					peer_manager.timer_tick_occurred();
 					peer_manager.timer_tick_occurred();