Some minor comment/doc tweaks in new monitor update blocking code

A few nits that came up in review to make the docs clearer, but not
anything super critical.

Author: TheBlueMatt

lightning/src/ln/channel.rs

@@ -433,6 +433,10 @@ pub(super) struct ReestablishResponses {
 }
 
 /// The return type of `force_shutdown`
+///
+/// Contains a (counterparty_node_id, funding_txo, [`ChannelMonitorUpdate`]) tuple
+/// followed by a list of HTLCs to fail back in the form of the (source, payment hash, and this
+/// channel's counterparty_node_id and channel_id).
 pub(crate) type ShutdownResult = (
 	Option<(PublicKey, OutPoint, ChannelMonitorUpdate)>,
 	Vec<(HTLCSource, PaymentHash, PublicKey, [u8; 32])>

lightning/src/ln/channelmanager.rs

@@ -5448,7 +5448,7 @@ where
 	}
 
 	/// Checks whether [`ChannelMonitorUpdate`]s generated by the receipt of a remote
-	/// [`msgs::RevokeAndACK`] should be held for the given channel until some other event
+	/// [`msgs::RevokeAndACK`] should be held for the given channel until some other action
 	/// completes. Note that this needs to happen in the same [`PeerState`] mutex as any release of
 	/// the [`ChannelMonitorUpdate`] in question.
 	fn raa_monitor_updates_held(&self,
@@ -6132,7 +6132,7 @@ where
 	/// When something which was blocking a channel from updating its [`ChannelMonitor`] (e.g. an
 	/// [`Event`] being handled) completes, this should be called to restore the channel to normal
 	/// operation. It will double-check that nothing *else* is also blocking the same channel from
-	/// making progress and then any blocked [`ChannelMonitorUpdate`]s fly.
+	/// making progress and then let any blocked [`ChannelMonitorUpdate`]s fly.
 	fn handle_monitor_update_release(&self, counterparty_node_id: PublicKey, channel_funding_outpoint: OutPoint, mut completed_blocker: Option<RAAMonitorUpdateBlockingAction>) {
 		let mut errors = Vec::new();
 		loop {