HTTP/2 streams closed due to client window update delay

[wtlucy]

Describe the bug
Liberty's HTTP/2 implementation enforces a non-configurable timeout for pending writes that are waiting for a window update from the client. That is, when a stream cannot write data due to a window size limitation, then the stream will only wait for the timeout period for a window update to arrive from the client - and once that deadline elapses the stream is reset. Currently this timeout is ~8s, which is insufficient for some scenarios - Liberty should wait for at least the configured writeTimeout period.

open-liberty/dev/com.ibm.ws.transport.http/src/com/ibm/ws/http/channel/h2internal/H2StreamProcessor.java

Lines 112 to 113 in 11e682d

	//change to 8192 to track better if this is occurring
	private final int MAX_TIME_TO_WAIT_FOR_WINDOW_UPDATE_MS = 8192;

Steps to Reproduce
On a HTTP/2 connection with Liberty, allow the write window for a stream to drop below 0, and don't send a WINDOW_UPDATE for that stream. The stream will get reset by Liberty after ~8s.

Expected behavior
Streams waiting on write window updates should be closed less aggressively by Liberty, and streams should not get closed before the writeTimeout period has elapsed.

Diagnostic information:

• OpenLiberty Version: n/a
• Affected feature(s): HTTP/2
• Java Version: n/a

Additional context
n/a

[pnicolucci]

@wtlucy please update the description of this release bug so that it follows/conforms to the Bug report template