Flow Control for HTTP/1.1 and HTTP/2

[azkrishpy]

Issue #, if available:

Description of changes:

Python API (awscrt/http.py, awscrt/aio/http.py):

• Added connection parameters: manual_window_management, initial_window_size, read_buffer_capacity
• Added HTTP/2-specific parameters: conn_manual_window_management, conn_window_size_threshold, stream_window_size_threshold
• Added Http2ClientConnection.update_window() for connection-level flow control
• Added HttpClientStreamBase.update_window() for stream-level flow control

C Bindings (source/http_connection.c):

• Extended aws_py_http_client_connection_new() to pass flow control options to aws_http_client_connection_options
• Added aws_py_http2_connection_update_window() → calls aws_http2_connection_update_window()
• Added aws_py_http_stream_update_window() → calls aws_http_stream_update_window()

Tests:

• FlowControlTest in test_http_client.py
• AIOFlowControlTest in test_aiohttp_client.py

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[TingDaoK]

explain all of those configuration more in the doc.

I really cannot tell what they are without digging into the implementation.

eg:

            stream_window_size_threshold (Optional[int]): HTTP/2 only. Threshold for sending
                WINDOW_UPDATE frames for streams. To reduce network traffic, the client batches
                window updates and only sends a WINDOW_UPDATE frame when the stream's flow-control
                window drops below this threshold. If None, a reasonable default value is used

[TingDaoK]

this is http/1.1 only.

The design is that AIOHttpClientConnectionUnified only takes configurations that applies to both protocol. The settings that only applies to one protocol should only be part of the protocol specific class.

[TingDaoK]

Explain this.

    /**
     * Optional
     * Capacity in bytes of the HTTP/1 connection's read buffer.
     * The buffer grows if the flow-control window of the incoming HTTP-stream
     * reaches zero. If the buffer reaches capacity, no further socket data is
     * read until the HTTP-stream's window opens again, allowing data to resume flowing.
     *
     * Ignored if `manual_window_management` is false.
     * If zero is specified (the default) then a default capacity is chosen.
     * A capacity that is too small may hinder throughput.
     * A capacity that is too big may waste memory without helping throughput.
     */
    size_t read_buffer_capacity;

It seems like it controls the buffer when the connection read from the socket while the data cannot be delivered to stream.

[TingDaoK]

Or, the easy thing to do is to not expose this. This really just control the memory usage if people wanted to. There is no current ask, and it seems a bit confusing about what it can be used. We can add them later if needed.