Remove a race-y debug assertion in new channel update handling

In 6090d9e we swapped out old
debug assertions that checked that a lock was `try_lock`able to
test that certain locks weren't held when we needed to be able to
take them in some near branch. However, another slipped in after in
the `ChannelMonitorUpdate` handling rework, which is replaced with
the new debug assertions here.

Author: TheBlueMatt

lightning/src/ln/channelmanager.rs

@@ -1588,7 +1588,7 @@ macro_rules! handle_new_monitor_update {
 	($self: ident, $update_res: expr, $update_id: expr, $peer_state_lock: expr, $peer_state: expr, $per_peer_state_lock: expr, $chan: expr, MANUALLY_REMOVING, $remove: expr) => { {
 		// update_maps_on_chan_removal needs to be able to take id_to_peer, so make sure we can in
 		// any case so that it won't deadlock.
-		debug_assert!($self.id_to_peer.try_lock().is_ok());
+		debug_assert_ne!($self.id_to_peer.held_by_thread(), LockHeldState::HeldByThread);
 		match $update_res {
 			ChannelMonitorUpdateStatus::InProgress => {
 				log_debug!($self.logger, "ChannelMonitor update for {} in flight, holding messages until the update completes.",