peer: in chanMsgStream release lock for condition var after msg q pop

In this commit we fix an existing bug within the msgConsumer grouting
of the chanMsgStream that could result in a partial deadlock, as the
readHandler would no longer be able to add messages to the message
queue. The primary cause of this issue would be if we got an update for
a channel that “we don’t know of”. The main loop would continue,
leaving the mutex unlocked. We would then try to re-lock at the top of
the loop, leading to a deadlock.

We avoid this situation by properly unlocking the condition variable as
soon as we’re done modifying the condition itself.

peer.go

@@ -566,6 +566,8 @@ func (c *chanMsgStream) msgConsumer() {
 		c.msgs[0] = nil // Set to nil to prevent GC leak.
 		c.msgs = c.msgs[1:]
 
+		c.msgCond.L.Unlock()
+
 		// We'll send a message to the funding manager and wait iff an
 		// active funding process for this channel hasn't yet
 		// completed. We do this in order to account for the following
@@ -587,7 +589,6 @@ func (c *chanMsgStream) msgConsumer() {
 		}
 
 		c.chanLink.HandleChannelUpdate(msg)
-		c.msgCond.L.Unlock()
 	}
 }