Add HTTP/2 support to HTTPClient

[HybridEidolon]

Describe the project you are working on

A desktop application that interacts heavily with a rich web API

Describe the problem or limitation you are having in your project

The HTTPClient and its high-level node analog HTTPResponse only support HTTP/1.1 in the TCP implementation, which is used in all platforms except Web. While the API is serviceable and the implementation is functional, only supporting 1.1 places additional request processing load on web servers and can increase transaction latency.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Minimally implement HTTP/2 support for TCP HTTPClient without changing the HTTPRequest node or the HTTPClient public interface.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

• Supporting the underlying protocol enough to handle HTTP/2 transactions sequentially on a single HTTPClient object, including compressed headers. Exclude features such as server push to retain the underlying HTTPClient API.
• Promote HTTPClient connections to HTTP/2 implicitly by default, if the server allows it.
• Support the same features in WebSocketPeer

This proposal deliberately excludes the possibility of handling multiplexed requests within HTTPClient, as its API would likely require significant changes to support it, leaving its implementation simpler. A redesigned HTTPClient for request multiplexing should also consider HTTP/3 over QUIC rather than focusing on HTTP/2.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No; TCP HTTPClient does not have sufficient extension points to expand its protocol support and thus would have to be reimplemented in GDScript or as a module or GDExtension.

Is there a reason why this should be core and not an add-on in the asset library?

Improving TCP HTTPClient to support HTTP/2 will bring it closer to web HTTPClient in implicit behavior and reduce unintended overhead against web API gateways, which some developers may encounter if their application becomes sufficiently popular. Those developers would be left to integrate a separate HTTP client in their existing code if they were to encounter issues on their backend.

I believe that there is room to support the HTTPClient class for web and native, while creating a new class for fine-tuned HTTP control that is native-only. Such an alternative client class could be implemented as an addon instead.

[Calinou]

cc @Faless