Response message tracing

[hannahhoward]

Goals

Trace the path of each out going response

Implementation

There are three layers of traces here:

1. Tracking each message sent through the message queue
   1. Produces: message -> sendMessage traces (where message encompasses the entire lifecycle of the message while sendMessage only covers the process of sending it over the wire)
2. Tracking each transaction in the ResponseAssembler
   1. Produces: response -> transaction -> execute-> message-build (where transaction encompasses the the whole transaction, execute encompasses the whole call to AllocateAndBuildMessage time including waiting for memory to be allocated, and message-build includes only the time building the messageQueue message)
   2. Links: message-build -> message span of the message the data ends up in
3. Tracking each block traversed in the QueryExecutor
   1. Produces: response -> executeTask -> processBlock
      1. -> loadBlock
      2. -> sendBlock -> processBlockHooks
   2. Links: sendBlock -> transaction

[rvagg]

maybe this should be renamed now to loadBlock, or call it loadCurrentBlock and don't return the link since it's now being pulled up to in the caller for span metadata so it's a pointless variable overwrite.

[rvagg]

The message-build naming convention thing is the thing that concerns me most, otherwise my other comments are just suggestions or requests for clarification.

The length of these traces is getting large, it'll be interesting to see them in diagnostic tooling! And yeah, graphsync_test.go is getting a bit out of hand with keeping up with the tracing. I really like how explicit it is, but it's probably getting a bit burdensome to keep updated, so maybe for now we should just remove the traces from a few of the tests where they're either super-simple cases or don't test anything novel about the traces.