#6238 Improve HTTP/2 flow control defaults

[arnabnandy7]

Motivation:

Large HTTP/2 request bodies, such as 10 MiB+ gRPC unary messages, can be extremely slow because the server uses the HTTP/2 protocol-default 65,535-byte stream and connection flow-control windows.

This change increases the server-side default stream window to 1 MiB and the connection window to 16 MiB, allowing large requests and concurrent streams to make progress with fewer flow-control update cycles. It also documents the distinction between stream-level and connection-level flow control and adds tests for the new defaults.

Client-side defaults remain unchanged.

Fixes #6238

Conformance:

I have signed the Eclipse Contributor Agreement and confirm that this contribution adheres to the Vert.x code style guidelines.

[vietj]

can you check what are the defaults in other libraries ?

[arnabnandy7]

can you check what are the defaults in other libraries ?

checking

[arnabnandy7]

@vietj I checked a few other implementations:

• Netty uses the HTTP/2 default of 64 KiB.
• gRPC-Java starts at 1 MiB and automatically adjusts the window using BDP estimation.
• gRPC-Go also uses dynamic flow-control tuning by default.
• HAProxy defaults to 64 KiB but recommends 1 MiB for large uploads over higher-latency connections.

Since Vert.x does not currently auto-tune the window, I used a larger static default to avoid repeatedly stalling on 64 KiB updates. The 1 MiB stream window is consistent with gRPC-Java.

The 16 MiB connection window was intended to allow several concurrent streams to make progress, but it might be better to use 1 MiB there as well for closer alignment with the other implementations. What do you think?

[vietj]

can you also apply this for HTTP client ?

[arnabnandy7]

can you also apply this for HTTP client ?

I'll try

[arnabnandy7]

can you also apply this for HTTP client ?

It's done, please review