BaseSocket async_write buffer lifecycle [API-1814] [API-1808] [API-1807]

[akeles85]

It seems that there is a problem with the lifecycle of invocations. When async_write method of the boost library is called, user should guarantee the validity of the buffer until the write operation complete. The invocations are added to an unordered_map with add_invocation_to_map method and erased when the response of the message is received or connection is closed. The problem occurs when the invocation is deleted as the response is received, and after that the write handler completion occurs. As the buffer is already deleted, boost async_write completion runs with deleted buffers and error occurs. We think that this case occurs when an async_write occurs while there is already a message in outbox.

A Sample scenario:

1. Invocation is sent and registered int he invocations map as shared_ptr, which also holds the ClientMessage which in turn holds the data to be transmitted at the wire.
2. The response is received and invocation is removed from the invocations map and hence the data to be transmitted put at the outbox of the writing side is now invalid pointer.
3. The handler that is executed after the write completes and at this line, if there is still new message in the queue, the new write operation is being called with the previous invocation, hence that invocation can not protect the life cycle of the new message to be written and this new message may be used after its associated invocation is deleted.

[devOpsHazelcast]

Windows test PASSed.

[devOpsHazelcast]

Linux test PASSed.

[OzanCansel]

As a general comment, could you run git-clang-format master to format ?

[devOpsHazelcast]

Windows test PASSed.

[devOpsHazelcast]

Linux test PASSed.

[devOpsHazelcast]

Windows test PASSed.

[devOpsHazelcast]

Linux test PASSed.

[devOpsHazelcast]

Linux test FAILed.

[devOpsHazelcast]

Windows test PASSed.

[devOpsHazelcast]

Linux test PASSed.

[devOpsHazelcast]

Linux test PASSed.

[devOpsHazelcast]

Windows test FAILed.