Adding more information and events to System.Net.Http telemetry

[MihaZupan]

Moving the remaining items out of #83734 to make tracking easier (the changes in the original issue were backported to 6.0 and 7.0).

We should consider including more information in the System.Net.Http events:

• Request information on RequestHeadersStart.
  While we log a lot of request information in RequestStart, we may end up sending multiple requests on the wire (redirects, retries) as part of a single RequestStart/Stop pair, and there is currently no way to tell from events where those requests are being made.
  Also while we log the request version in RequestStart, there is no reliable way to get the protocol version that was actually used as a result of ALPN/version policy from events (in some cases it is implied if you see other events like RequestLeftQueue).
  The following is the same parameter signature as RequestStart with the exception of omitting the HttpVersionPolicy since it doesn't have meaning at this layer (we already know exactly what version we're using).

  -void RequestHeadersStart();
  +void RequestHeadersStart(string scheme, string host, int port, string pathAndQuery, byte versionMajor, byte versionMinor);

  Alternatively, the connection-level information (scheme, host, port, version) could be left out of this event, and instead be exposed in a way where the user could map connections to requests. E.g.

  -void ConnectionEstablished(byte versionMajor, byte versionMinor)
  -void ConnectionClosed(byte versionMajor, byte versionMinor)
  +void ConnectionEstablished(byte versionMajor, byte versionMinor, long connectionId, string scheme, string host, int port, string? remoteEndPoint)
  +void ConnectionClosed(byte versionMajor, byte versionMinor, long connectionId)
  +void RequestHeadersStart(long connectionId);

• A new event indicating a redirect.
  This should include the new Uri we are going to try redirecting to. I don't have a strong opinion on including the whole Uri vs separating the scheme/host/port/path...

  +void Redirect(string redirectUri);

[ghost]

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

Issue Details

---

Moving the remaining items out of #83734 to make tracking easier (the changes in the original issue were backported to 6.0 and 7.0).

We should consider including more information in the System.Net.Http events:

• Request information on RequestHeadersStart.
  While we log a lot of request information in RequestStart, we may end up sending multiple requests on the wire (redirects, retries) as part of a single RequestStart/Stop pair, and there is currently no way to tell from events where those requests are being made.
  Also while we log the request version in RequestStart, there is no reliable way to get the protocol version that was actually used as a result of ALPN/version policy from events (in some cases it is implied if you see other events like RequestLeftQueue).
  The following is the same parameter signature as RequestStart with the exception of omitting the HttpVersionPolicy since it doesn't have meaning at this layer (we already know exactly what version we're using).

  -void RequestHeadersStart();
  +void RequestHeadersStart(string scheme, string host, int port, string pathAndQuery, byte versionMajor, byte versionMinor);

  Alternatively, the connection-level information (scheme, host, port, version) could be left out of this event, and instead be exposed in a way where the user could map connections to requests. E.g.

  -void ConnectionEstablished(byte versionMajor, byte versionMinor)
  -void ConnectionClosed(byte versionMajor, byte versionMinor)
  +void ConnectionEstablished(byte versionMajor, byte versionMinor, long connectionId, string scheme, string host, int port, string? remoteEndPoint)
  +void ConnectionClosed(byte versionMajor, byte versionMinor, long connectionId)
  +void RequestHeadersStart(long connectionId);

• A new event indicating a redirect.
  This should include the new Uri we are going to try redirecting to. I don't have a strong opinion on including the whole Uri vs separating the scheme/host/port/path...

  +void Redirect(string redirectUri);

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