HTTP 1.0 servers close the connection automatically after sending the
response. We updated the http.Client actor such that the users can use
the high-level API like making several requests in a row without having
to worry about reconnects. http.Client will buffer the requests and
flush the buffer once it (re)connects the socket.

Writing to a closed socket is bad and guaranteed to fail, so the user
(in this case the http.Client actor) should be notified ASAP before
making further writes. Rather than using the on_error callback from the
underlying TCPConnection and TLSConnection actors we raise an exception
from their write() methods. This implies the calls to write() are
synchronous, but since we're not waiting on network I/O it should be
fine?!

Add some basic heuristics, like when we create a http.Client the first
time we obviously connect directly then we expect to run at least one
query. Maybe we should not reconnect after that (in case of HTTP / 1.0
or not having persistent in later HTTP versions) until there is a second
query. Now if we see a second query we can assume "there are multiple
requests" and thus reconnect directly after the 2nd and subsequent
requests.

By grouping the socket errors under ConnectionError we can be more
precise in handling the error in consumers of TCP connection actors.