Add `reconnects` parameter to tcp client transport

We ran into a bug in production today where haproxy had a port bound
with no backends, so it was immediately returning a null response. This
caused the client TcpTransport to get stuck in an infinite loop, since
it resets its `retry` count back to 0 after establishing a successful
connection.

Rather than trying to establish heuristics for when is 'too soon' to
receive an `end` event, I'm adding a new `reconnects` parameter to
control how many reconnects are acceptable before marking the connection
as dead.