Use a new buffer to avoid race conditions

[gabsn]

Here we do 2 things:

1. We use a new buffer before sending the encoder through the network to avoid race conditions (the new buffer uses the same underlying data, so there is no performance overhead)
2. We stop fully reading the response, to avoid those logs:

Unsolicited response received on idle HTTP channel starting with "HTTP/1.1 400 Bad Request\r\nContent-Type: text/plain; charset=utf-8\r\nConnection: close\r\n\r\n400 Bad Request"; err=<nil>

Actually, this trick is according to people able to improve the client performances by reusing persistent connections, but it's not documented in the official golang documentation. Moreover, we had those unwanted logs by doing this. So my point here is we should not use this unsafe trick in such an important part of the trace and rather consider using a grpc library like this one that will natively use HTTP2.

I also considered using a pool of buffers to avoid reallocating memory, but it was still leading to race conditions. Indeed, once the function client.Do(req) has been called, the persitentConn.writeLoop goroutine will be spawned with a reference on the buffer, and will try to read it later, even when we will put the buffer back to the pool. That's why to be safe, it's preferable to create a new buffer each time we call client.Do (again, we don't really create a new buffer, since we reuse the underlying slice of bytes).

[palazzem]

probably we can add a lock to be sure it's thread-safe