Propagate trace parent to SignalR hub invocations

[JamesNK]

Addresses #51557. Specifically, the Distributed tracing (trace ids sent between client and server) item.

Follow up to #55439. The previous PR added activities for signalr server invocations. However, the server hub invocation activity never has a parent, so the activity always starts a new trace. This PR updates signalr to get trace information from the hub invocation message headers, which are set by the client, when it creates the activity.

The benefit of this change is you can now see the context of the hub invocation. For example, if web api sends a hub invocation to SignalR, the hub invocation span is nested beneath the web api span.

Changes:

• SignalR server changed to not clear the request activity when a connection starts. I believe this is an improvement because we want most telemetry on the connection (e.g. logging and OnConnected and OnDisconnected activities) to be correlated to the request activity.
• SignalR server changed to clear and restore the request activity when invocations are run. These are the pieces of telemetry we don't want to be a child of the request activity.
• .NET SignalR client sets tracing headers on hub invocation request if there is an activity. Headers are sent with the invocation to the server.
• SignalR server reads trace headers and creates an activity from the remote parent. Shares logic with ASP.NET Core for creating activity from remote.

Not planned in this PR:

• Creating an activity for sending the invocation in .NET client.
• Sending tracing headers from other clients.

Nothing is blocking these from being added in the future.

TODO: Write tests for client. Write integration test for client to server.

[JamesNK]

@noahfalk @tarekgh It would be great if you could double check the mechanics of sending/receiving trace headers and activity usage are correct.

[JamesNK]

This centralizes and shares ASP.NET Core's code for created an activity from a remote source. Now used by ASP.NET Core hosting and SignalR.

[JamesNK]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[tarekgh]

LGTM

[BrennanConroy]

I was kind of expecting the Javascript client to be done as well. It's the most used client (.NET is second) and we generally like to add new features to both JS and .NET to have some verification that the concept works across languages.

[JamesNK]

I was kind of expecting the Javascript client to be done as well. It's the most used client (.NET is second) and we generally like to add new features to both JS and .NET to have some verification that the concept works across languages.

I've never done OTEL from JavaScript before. I don't know if I'd have time to do it for .NET 9. What would you like to do?

Note, there will probably be some dependencies required for working with OTEL in JavaScript. In .NET we have APIs built into runtime for this stuff. JavaScript requires packages, e.g. https://www.npmjs.com/package/@opentelemetry/core for setting propagated headers. And a higher level OTEL packages for setting a client span if that's also in the JavaScript client.

[noahfalk]

LGTM as well.

@tarekgh - in a future release we might want to offer an improved overload of ActivitySource.CreateActivity so that callers don't need these workarounds. It looks like one extra parameter to specify HasRemoteParent and a 2nd to allow creating an activity even when there is no listener would probably reduce the calling code by ~75 lines.

[JamesNK]

@BrennanConroy I have a PR for adding a client activity source and activities in #57101. That PR uses this one as its target branch.

Please take some time to see if there are any outstanding changes required or whether it is ok to merge. That will allow the client activity source PR to be retargeted to main.