f - Update lock order tree docs again

Author: ViktorTigerstrom

lightning/src/ln/channelmanager.rs

@@ -670,27 +670,33 @@ pub type SimpleRefChannelManager<'a, 'b, 'c, 'd, 'e, M, T, F, L> = ChannelManage
 //
 // Lock order:
 // The tree structure below illustrates the lock order requirements for the different locks of the
-// `ChannelManager`. If two or more locks on the same branch is held at the same time, locks should
-// be taken in the order of the lowest to highest level in the tree.
+// `ChannelManager`. If two or more locks on the same branch are held at the same time, locks
+// should be taken in the order of the lowest to the highest level in the tree.
 //
 // Lock order tree:
-// │
-// │──`channel_state`
-// │   │
-// │   │──`id_to_peer`
-// │   │
-// │   └──`per_peer_state`
-// │       │
-// │       │──`best_block`
-// │       │
-// │       └──`pending_inbound_payments`
-// │           │
-// │           └──`pending_outbound_payments`
-// │               │
-// │               └──`pending_events`
-// │                   │
-// │                   └──`pending_background_events`
-// │
+//
+// `total_consistency_lock`
+//  │
+//  │──`forward_htlcs`
+//  │
+//  │──`channel_state`
+//  │   │
+//  │   │──`id_to_peer`
+//  │   │
+//  │   └──`per_peer_state`
+//  │       │
+//  │       │──`outbound_scid_aliases`
+//  │       │
+//  │       └──`pending_inbound_payments`
+//  │           │
+//  │           └──`pending_outbound_payments`
+//  │               │
+//  │               │──`best_block`
+//  │               │
+//  │               └──`pending_events`
+//  │                   │
+//  │                   └──`pending_background_events`
+//
 pub struct ChannelManager<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref>
 	where M::Target: chain::Watch<Signer>,
         T::Target: BroadcasterInterface,
@@ -758,6 +764,8 @@ pub struct ChannelManager<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref,
 	/// and some closed channels which reached a usable state prior to being closed. This is used
 	/// only to avoid duplicates, and is not persisted explicitly to disk, but rebuilt from the
 	/// active channel list on load.
+	///
+	/// See `ChannelManager` struct-level documentation for lock order requirements.
 	outbound_scid_aliases: Mutex<HashSet<u64>>,
 
 	/// `channel_id` -> `counterparty_node_id`.