fixing timeouts for ackable messages

[KKhurin]

This fixes the longstanding problem with sporadically having ack timeouts when adding connections to groups.

• the culprit behind the timeouts is a race condition when sending service message to several endpoints simultaneously which may lead to overriding AckId of a message that has not been sent yet
• the stickiness to the service connection (introduced in SDK 1.7.1) makes this race condition happen a lot more often due to increased likelihood of going async (and increased chance of the race condition) because many scenarios would use the same connection with higher concurrency.

Fixes #745
Fixes #1225

[vicancy]

Quote @vwxyzh 's proposal below which avoids changing the protocol

Change https://github.com/Azure/azure-signalr/blob/dev/src/Microsoft.Azure.SignalR.Common/ServiceConnections/ServiceConnectionContainerBase.cs#L245 to

RawMessage raw = null;

lock (ackableMessage)
{
  ackableMessage.AckId = id;
  raw = WriteRawMessage(ackableMessage);
}

[KKhurin]

Quote @vwxyzh 's proposal below which avoids changing the protocol

Change https://github.com/Azure/azure-signalr/blob/dev/src/Microsoft.Azure.SignalR.Common/ServiceConnections/ServiceConnectionContainerBase.cs#L245 to

RawMessage raw = null;

lock (ackableMessage)
{
  ackableMessage.AckId = id;
  raw = WriteRawMessage(ackableMessage);
}

Didn't originally choose this because of:

1. it allocates bytes for the raw message much earlier than it currently does - e.g. increases memory pressure (although making a copy also adds an extra allocation which by its nature should be smaller than the serialized one).
2. introduces a lock which is arguably heavier than the shallow member-wise clone.

I like the simplicity of @yzt's approach if we can accept the new method in ServiceMessage.