Towards better tracking of gateway performance

We need to start tracking gateway response latencies a bit better. Doing so will give us some really valuable information about where our efforts will be best applied in making ipfs faster.

For every request that comes in, unless we already have it cached, we generally spend some amount of time searching for peers who have the content, and then some amount of time connecting to said peers, and then finally some amount of time actually fetching that content.

The average request consists of a single hash. In this case, the first node gets resolved by `ResolvePath`. All of the content routing work and swarm dialing work happens during the execution of a single 'dag.Get' call. I suspect this is where the bulk of the latency comes from. Within dag.Get this work is further abstracted down into bitswap. Bitswap will search for peers, connect and then request data for each request internally.

My approach would be to pass some sort of request ID down along with the context, hoping it makes it all the way to bitswap, then use that to tie log timing information about how much time is spent in which activities to a given request.

cc @Stebalien @hannahhoward @frrist