[release/6.0-staging] Add status code and exception info to System.Net.Http events

[MihaZupan]

Backport of #84036 to 6.0.
Contributes to #83734.

Customer Impact

The networking stack is already instrumented with EventSource events that allow telemetry consumers to observe when requests are made and where they are spending time. Aside from a timestamp, these events often provide no or very few extra details.

On .NET Framework, a different EventSource provider exists that exposes information like the HTTP response status code. This provider does not exist on .NET Core+, and as a result, customers migrating their services from Framework are losing diagnostics information (e.g. XBox Live service).

This PR adds the response status code and exception message to existing events to cover that gap.

Testing

I added targeted CI tests that confirm new parameters are included in events.

Risk

Minimal.
Impacted code paths are all only reachable when telemetry is enabled.
With confirmation from @brianrob and @noahfalk, modifications to existing events in the manner done here are safe and non-breaking for existing telemetry consumers.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #84036 to 6.0.
Contributes to #83734.

Includes the following changes:

-void RequestStop()
+void RequestStop(int statusCode)

-void ResponseHeadersStop()
+void ResponseHeadersStop(int statusCode)

-void RequestFailed();
+void RequestFailed(string exceptionMessage)

Does not include the new RequestFailedDetailed event added by #84036 as its usefulness is limited before 8.0 due to #84712.

Customer Impact

TODO

Testing

I added targeted CI tests that confirm new parameters are included in events.

Risk

TODO

Author:	MihaZupan
Assignees:	MihaZupan
Labels:	area-System.Net.Http
Milestone:	6.0.x

[ManickaP]

LGTM, thanks.

[MihaZupan]

Approved by Tactics (Steve Carroll) on May 1st via email. Marking as servicing-approved.

[MihaZupan]

@carlossanlop we are free to merge these now, right?

[carlossanlop]

we are free to merge these now, right?

Yes. PR owners are free to merge their backport PRs targeting the release/X.0-staging any time of the month. No need to wait for branding anymore. Just be mindful of the code complete date, since that's what determines which Release will get your fix. In the case of this PR, if you merge it now, it will go into the June Release. The code complete date is May 15th.

For future reference, you can use this checklist:

• If affecting feature code: Approved by Tactics.
• If Approved by Tactics, or it is a test-only or an infra-only change: The Servicing-approved label is applied, which lets the check-service-labels CI leg to pass.
• Signed-off by area owner.
• CI is green, or failures are investigated and determined to be unrelated to this change.
• If the affected assemblies publish OOB packages, the required OOB package authoring changes are included in this PR.