SSL connection may potentially hang forever

If the application send a pipe of requests to memcached it is possible that the connection object gets into a state where it waits for the client to send more data, but the client is done sending all of the data (but it is buffered internally our ssl object).

This happens if the client send more than one (mcbp) packet and all of those packets gets read off the network, but we failed to move all of the data from the socket buffer into the SSL buffer AND when we read off the SSL buffer we filled rbuf with exactly enough bytes so that the next byte stored in the ssl buffer was a new command. 

Note that the read path in memcached will try to "drain" the buffer in a loop trying to read first 2 k, if we can get 2k we read additional 2k.. if that is ok we read additional 4 k, and if that is ok we read additional 8k and spool that up internally in our rbuf. From my understanding this must match exactly to the boundary of a mcbp packet (if all of this data wasn't available immediately things would work differently as we would then buffer slightly differently)...

Clients will probably time out the operation, and if they close the connection the resources is being freed on the server side.