Fix stack overflow in HttpStreamOverHttp3.consumeAvailable()

[lorban]

Only H3 seems to suffer from the stack overflow problem.

What I do not like about this "fix":

• there is no easy way to test it
• it exposes that all protocols leak buffers on the server when a timeout occurs

Fixes #10543

[gregw]

I'm wondering if we should start using SoftReference in our RetainableByteBuffer to link to the ByteBuffer. We would also have a hard reference, which we would set when the buffer is in the pool, and null when we allocate the buffer. If we ever get a buffer in the collection queue, we then know that somebody took a RetainableByteBuffer and leaked it. However, I'm not exactly sure how we would recover from that, as I'm not sure how we can use the collected ByteBuffer to find the RetainableByteBuffer reference?

[lorban]

@gregw Looking at the ConcurrentPool implementation, it may be possible to keep both a hard and a weak reference to the pooled object and null out the hard ref when the pooled object is acquired, then assign it back to the hard reference when it is released. We could then "garbage collect" the pool with a timer by removing all entries that have a null WeakReference.

That looks feasible and would make our pools totally resistant to leaks like they used to be. We should investigate this idea. I filed #10569 so that we can come back to that subject later on.

[lorban]

@sbordet I streamlined the H1 consumeAvailable impl; actually the fix for the memory leak should have been in HttpConnection.fillRequestBuffer().

But the code I added to H3 should be considered a workaround. There is something more fundamental that is wrong with the way H3 handles exceptions in the lowest layers. I'm going to open an issue about it.

[gregw]

I'm good with this for this release cycle, so long as we get onto #10569 asap next cycle.