Fix truncated values when the peer closes mid-response

[ianks]

Previously, ConnectionManager#read / #read_exact did a single @sock.read(count). IO#read(maxlen) is fread-like: it returns exactly maxlen bytes unless the stream hits EOF, in which case it hands back a shorter (non-nil) buffer with no exception. So if the server closes the connection partway through a response body (memcached restart, proxy timeout, connection reset), we'd read a truncated body and surface it as a valid value, a decodable-but-wrong value that then gets returned/cached. This PR fixes that by reading until we have exactly count bytes, and raising on a premature EOF so the dirty socket gets closed and retried instead of reused.

The happy path is unchanged and allocation-free: a healthy socket fills count in a single read, so we return that buffer directly. Only a short read (the mid-response EOF case) falls through to the accumulation loop.

How it works

• read and read_exact both go through a read_bytes helper
• fast path: one @sock.read(count), returned directly when it's already the full length
• slow path: loop reading the remainder, and a nil/empty chunk before count bytes raises, which closes the socket and lets the client retry on a fresh connection

The integration test uses a real TCP server that truncates the first response and closes the socket, then serves the full body on the retry. Before this change it returned the truncated value, now the client transparently retries and gets the right one.

[mrattle]

Just a small comment on how we're raising but otherwise this looks good to me.

[mrattle]

The read and read_exact methods already rescue EOFError and then call error_on_request! in their rescue blocks. Can we just raise EOFError here instead and leverage that existing rescue?

down! (source) called from inside error_on_request! uses $ERROR_INFO for context, which we might be losing by raising with the raw string here.

[ianks]

@mrattle good callout, addressed in d582ac5