Add response_time and body_read_time metrics

[pushrax]

This will help determine the source of latency.

With a test that queries 2 rows that each have ~64k of attributes, the metrics object looks like this:

    {
      approx_namespace_size: 2,
      cache_hit_ratio: 1,
      cache_temperature: 'hot',
      processing_time: 56,
      exhaustive_search_count: 2,
      response_time: 92.14187500000003,
      body_read_time: 66.29495799999995
    }

The rtt latency from my laptop to us-central is 30ms, so it makes sense that 56ms of processing time + 30ms is around 90ms. Then it seems an additional 2 roundtrips worth of latency happen to finish reading the body.

To get a finer grained idea of what's happening inside body_read_time, we'd have to manually handle gunzip and json decoding, which we might want to do just for the better timing. But this seems like a good start.

[pushrax]

also would like to get the tcp connect time instrumented but I couldn't find a way to do that without using a much lower level http implementation