Enhancement/#1312 add in distributed tracing

[thompson-tomo]

Description

To improve traceability activities are now being created so that external requests can be traced

Closes #1312

Quality checklist

• [x] Your code complies with our Coding Style.
• [x] You've updated documentation for your change, where applicable. If your change affects other repositories, such as Documentation, Samples and/or MainSite, add linked PRs here.
• [x] There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

[bart-vmware]

I don't see the point of adding this, am I missing something? ASP.NET already provides built-in tracing for HttpClient usage.

[thompson-tomo]

Without this change the log messages being generated by steeltoe do not have the tracing properties (trace, transaction & span) hence I was ending up with alot of messages missing the tracing properties.

Note most of the changes are whitespace due to introduction of the using statements.

[TimHess]

How are tracing properties useful on these items?

These interactions are typically called in the background rather than as a part of any distributed interaction.

[thompson-tomo]

So what i was noticing is that for example the background requests to eureka server, i was not able to correlate the logs being generated prior to the http requests with the server processing of the request and at the same time was not able to connect the processing of the response to the original request.

[bart-vmware]

I don't understand why a periodic background request to eureka should be correlated to an incoming request. There's no relationship between those execution flows. For example:

18:43:01 Incoming HTTP request at /api/shoppingbasket, correlation ID matching click in UI 18:43:05 Incoming HTTP request at /api/shoppingbasket, correlation ID matching click in UI 18:43:08 Incoming HTTP request at /api/shoppingbasket, correlation ID matching click in UI 18:43:09 Outgoing eureka request, no correlation 18:43:12 Incoming HTTP request at /api/shoppingbasket, correlation ID matching click in UI

[thompson-tomo]

The reason for me is so that the logs generated prior to the transmission ie

18:43:09 Outgoing eureka request

Can be correlated through the logs as the request traverses the environment ie via a reverse proxy/load balancer & then ideally your eureka/consul server etc. At the same time there was some endpoints which weren't generating activities.

[TimHess]

I just tested this on Steeltoe v4 with OpenTelemetry configured to instrument HttpClient, and all outbound requests are recorded. It does not appear to make a difference when viewing the traces in Zipkin whether or not Steeltoe wraps these interactions in another Activity. If we missed something, please let us know, but I don't currently see a benefit in taking these changes