Reintroduce locking around socket writes

when transmitting multiple frames at once.

While changes in #350, #354 are supposed to be safe, there's some
evidence (#681) that sometimes they are not which leads to incorrect
byte stream interleaving on the wire.

Author: michaelklishin

projects/client/RabbitMQ.Client/src/client/impl/Command.cs

@@ -134,7 +134,10 @@ public void TransmitAsFrameSet(int channelNumber, Connection connection)
                 }
             }
 
-            connection.WriteFrameSet(frames);
+            // synchronise multi-frame writes as particularly risky
+            lock(connection.SocketWriteLock) {
+                connection.WriteFrameSet(frames);
+            }
         }
 
 

projects/client/RabbitMQ.Client/src/client/impl/Connection.cs

@@ -66,6 +66,7 @@ namespace RabbitMQ.Client.Framing.Impl
     public class Connection : IConnection
     {
         private readonly object m_eventLock = new object();
+        private object m_socketWriteLock = new object();
 
         ///<summary>Heartbeat frame for transmission. Reusable across connections.</summary>
         private readonly EmptyOutboundFrame m_heartbeatFrame = new EmptyOutboundFrame();
@@ -271,6 +272,11 @@ public event EventHandler<ConnectionRecoveryErrorEventArgs> ConnectionRecoveryEr
                 }
             }
         }
+
+        public object SocketWriteLock {
+            get { return m_socketWriteLock; }
+        }
+
         public string ClientProvidedName { get; private set; }
 
         public ushort ChannelMax