feat(responsemanager): trace full messages via links to responses

[rvagg]

Fixes: #318

Probably the most interesting part of this is seeing two separate messages do different things to a single response. In TestPauseResumeViaUpdate we see the first message linked to the start of a response and the second message get linked to the processUpdate span of the same response. Then in TestCancellationQueryInProgress we see the same thing but for an abortRequest triggered by the second message.

One possible change could be that we use this new message span as the parent to a response if no other parent gets inserted via the reuqestqueued context-modifying hook. So all response spans would have a message parent unless that hook is wired up by a consumer, as we do in TestIncomingQuery and I believe we'll be doing in datatransfer or further upstream. But I think this might miss the point of keeping responses as separate things that are independent of the individual messages. The message span isn't going to live longer than the synchronous call here but I don't think it would matter to a consuming API if they stacked up, but it does suggest that we're looking at these things in different ways so we should probably keep them separate .. ?

[hannahhoward]

Do you mind changing the name of message span to requestMessage to mirror the responseMessage on the other side and make it less generic? Otherwise LGTM

[hannahhoward]

rename requestMessage to match corresponding responseMessage on the other side (also cause I'm about to submit a PR that conflicts :)

[hannahhoward]

And yes, we should keep the design as is

[hannahhoward]

@rvagg I merged your other PR first -- do you now want to make this processRequests for consistency?

[rvagg]

yes, I didn't even think about the responsemanager when I did that one, but it's done here now, and ooof that was a painful rebase but this is now up to date as well

[rvagg]

@hannahhoward the failure on windows is a missing response(0)->executeTask(0)->processBlock(0)->loadBlock(0) trace in TestNetworkDisconnect. This doesn't come from the change in this PR. Do we need to remove all the response(X)->executeTask(Y)->* traces from that test, is it reasonable that they may be missing in some circumstances from this test?