Fix flaky testUploadWithPendingReadConcurrentServerCloseClosesStream()

[lorban]

Fixes #11692

[sbordet]

Is this relevant for the fix?

[lorban]

It's not, but it avoids a warning from the JVM when running on JDK 22. Do you want me to move that change to another PR?

[sbordet]

It's not clear... you mean that the demand is not invoked at all, or that it is invoked, but not with an error chunk?

I think serverDemandLatch must be counted down, i.e. the demand must be invoked with an error chunk.
If the problem is that the connector is stopped when inside the demand callback with a normal chunk, then either we should convert the implementation into a loop (so we read the error chunk), or setting the demand when there was a failure should invoke immediately the demand again.

[lorban]

The problem lies in HTTP2ServerConnection.onStreamFailure() which does the following:

Runnable task = channel.onFailure(failure, callback);
if (task != null)
{
    // We must dispatch to another thread because the task
    // may call application code that performs blocking I/O.
    offerTask(task, true); // true means call strategy.dispatch()
}

Since it is the task returned by channel.onFailure() that eventually services the demand, there is no guarantee that it's going to be executed as there is a race condition between the strategy's thread executing the queued task and the strategy being stopped because it is part of the connector being stopped.

[lorban]

@sbordet I've submitted an alternate fix for the flakyness of that test that requires a delicate change in HTTP2Connection to guarantee a pending demand is serviced even if the connector gets stopped.