Batching RPCs over TLS causes stuck RPCs

[xqrzd]

Very obscure bug. If 2 RPCs get sent in the same buffer to Socket.WriteAsync(), we only receive the data for the first RPC from Socket.ReceiveAsync(). Both RPCs are received by Kudu, if the client disconnects while waiting for the 2nd RPC response, the server prints this:
W0130 19:40:45.970429 934 connection.cc:554] Connection torn down before Call kudu.master.MasterService.GetTableLocations from 10.0.2.2:51671 (request call id 3) could send its response
The 2nd RPC can be unstuck by sending an additional RPC, suggesting somewhere a buffer isn't being flushed in this scenario.

For now there is a hack-fix in place to prevent multiple RPCs being sent in a single call to Socket.WriteAsync(), at the cost of some efficiency.

[xqrzd]

This doesn't reproduce anymore in Kudu 1.12+, guessing this is the commit that fixed it: apache/kudu@1a21e92

Will need to look into options for removing the hack-fix on Kudu 1.12 and newer.