Backport of #97881 to release/6.0-staging

Fixes #97131

Customer Impact

Problem: gRPC server-streaming connections may be closed by server when communicating with service on GCP behind Google Cloud L7 External Load Balancer. It depends on size and frequency of gRPC messages.
Reported by customers in grpc/grpc-dotnet#2361 and grpc/grpc-dotnet#2358

gRPC is built on top of HTTP/2 protocol. In 'HttpClient' we use PING frames to measure RTT (Round-Trip Time) to leverage connections efficiently. Our usage of PING frames triggers DoS protection in Google Cloud L7 External Load Balancer and they close the connection from the server side. They are unwilling to change their implementation.
We worked with them to design ordering of frames mixed with WINDOW_UPDATE frames in a way that will avoid triggering their DoS protection and will allow us to measure RTT.

Regression

No. The behavior is specific to Google Cloud L7 External Load Balancer.

Testing

• A functional test has been added to emulate the customer scenario.
• The change has been manually tested against customer endpoint (i.e. GCP-hosted service behind Google Cloud L7 External Load Balancer).

Risk

Low-Medium

We are now sending higher volume of WINDOW_UPDATE frames. In theory, some servers might have problem with that. Mitigations:

• We have a pre-existing switch to turn off RTT measurements entirely - System.Net.SocketsHttpHandler.Http2FlowControl.DisableDynamicWindowSizing
• grpc-go client implementation has exactly same behavior which we are proposing for many years now (although it is gRPC only, not general HTTP/2 as our)
• We did code review of popular HTTP/2 implementations -- nginx and nghttp2. We didn't find any DoS protection mechanism that would be triggered by more WINDOW_UPDATE frames.