Add WebSockets telemetry

[MihaZupan]

Fixes #1209

I followed the approach outlined in #1209 of wrapping the upgrade feature and MITM the upgrade transport stream.

Public API is just the UseWebSocketsTelemetry extension method.
I fed the data to an EventSource event, but it could also alternatively be something like IWebSocketsTelemetryFeature.

I didn't know where to put the code so I made a WebSocketsTelemetry folder in the main project (all types are internal though).

ToDo: I will add tests when we're happy with the overall approach

[Tratcher]

It looks like the right structure. Testing is going to be interesting.

Work with the customer to decide the right field types for the telemetry output.

[Tratcher]

The close is only graceful if both sides acknowledge it. Otherwise you can attribute the reason as a disconnect by the unacknowledged side.

Suggested change

	if (clientCloseTime.HasValue && (!serverCloseTime.HasValue || serverCloseTime.Value > clientCloseTime.Value))
	if (clientCloseTime.HasValue && serverCloseTime.HasValue && serverCloseTime.Value > clientCloseTime.Value)

https://datatracker.ietf.org/doc/html/rfc6455#section-7.1.2

Once an endpoint has both sent and
received a Close control frame, that endpoint SHOULD Close the
WebSocket Connection as defined in

[MihaZupan]

So something like

if (clientSentClose && serverSentClose)
{
    return clientCloseTime < serverCloseTime ? ClientGraceful : ServerGraceful;
}
else
{
    Disconnect
}

?

[Tratcher]

if (clientSentClose && serverSentClose)
{
    return clientCloseTime < serverCloseTime ? ClientGraceful : ServerGraceful;
}
else if (clientSentClose)
{
    ServerDisconnect
}
else if (serverSentClose)
{
   ClientDisconnect
}
else // check forwarder errors

[MihaZupan]

If the client sends a Close message and immediately closes the connection (without waiting for the server to respond), we would be reporting that as a ServerDisconnect (and vice-versa).

Would that be the desired behavior?

[Tratcher]

Interesting... how would you detect that? Would the read return 0? Writes might fail, depending on the timing.

[MihaZupan]

I changed the logic so that it is now

if (clientSentClose && serverSentClose)
{
    return clientCloseTime < serverCloseTime ? ClientGraceful : ServerGraceful;
}

// One side sent a WebSocket close, but we never saw a response from the other side
// It is possible an error occurred, but we saw a graceful close first, so that is the intiator
if (clientSentClose)
{
    return ClientGraceful;
}
if (serverSentClose)
{
    return ServerGraceful;
}

return forwarderError ...

While "graceful" doesn't necessarily mean "both sides sent close", I believe reporting what likely initiated the close is more useful as the WebSocketCloseReason.
Either side may still perform protocol violations, but it's not our aim to catch that.

[MihaZupan]

This appears to be a bug where if the request copy finishes first successfully, we will attribute potential response errors to the request side.

[adityamandaleeka]

@MihaZupan Are you waiting for anything from anyone on this PR?

[Tratcher]

I was expecting some unit tests for the WebSocketsParser?

[MihaZupan]

Added more tests

[Tratcher]

Have you tried running this in the sample with real websocket traffic?

[MihaZupan]

Yes, I tried it with a simple demo app and the default Blazor template, and it's working as expected.