server: keep connections open if we're writing a lot

Writing data to a closed socket (remote) will succeed.  The next write
will raise an error as the underlying subsystem has detected the
previous write failed.  This means we lose a metric without us noticing.
For that reason we initially reconnected for each batch we did so we
tried reconnecting fairly often and see the failure at that stage.
Downside of that is that we open a lot of sockets, which keep lingering
around a while on servers.  Hence, some hybrid solution, keep the
connection alive as long as we have work.  As soon as we're idle,
disconnect.
server_queuereader: update docs
server_queuerunner: claim a bunch of metrics to write

It feels kind of pointless, but dequeue a whole bunch at a time in a
local "queue" to send it.  Advantage of the local queue is that we don't
have to push back into the queue, and don't have locking overhead, since
we're the only one reading from it.  So overall, this improves
performance at the expense of some memory.
dispatcher: avoid blocking dispatcher threads

Implemented a state in server sending, such that blocking operations
cause the dispatcher to move on, keeping the client waiting.  This
allows the dispatchers to keep on going, doing whatever they /can/ do,
instead of blocking for the clients it serves.