Fix Netty ByteBuf leak in GatewayServerErrorInjector fault injection delay paths

[jeet1995]

Description

Fixes Netty ByteBuf leaks in GatewayServerErrorInjector when fault injection simulates response delays under HTTP/2.

Root Cause

When fault injection simulates a response delay via delayElement, the real HTTP response body was discarded without draining its ByteBuf content. Under HTTP/1.1, connection closure masks this because all ByteBufs are released when the channel closes. Under HTTP/2, the parent connection stays pooled and the undrained ByteBufs accumulate on the parent channel's allocator — causing growing memory leaks.

Fix

Two leak paths in injectGatewayServerResponseError:

Path	Scenario	Fix
delay >= timeout	Response arrives but is discarded by .then(Mono.error(ReadTimeoutException)) — body is never consumed	doOnNext drains and releases the body before delayElement buffers the response
delay < timeout	In the happy path the response flows downstream after the delay and the caller drains the body normally. However, if the downstream cancels during delayElement (e.g., an outer timeout fires), delayElement silently drops the buffered HttpResponse without emitting it	doOnDiscard(HttpResponse.class, ...) catches that discard and releases the body ByteBuf to prevent leaks

Both paths call releaseResponseBody() which subscribes to the body flux and ReferenceCountUtil.safeRelease()s each ByteBuf — consistent with existing patterns in ReactorNettyClient.java.

Testing

• Needs validation with PerPartitionCircuitBreakerE2ETests (thin-client + HTTP/2 path)
• Prior run with similar fix reduced leaks from 72 to 2 (remaining were pre-existing NIO/SslHandler leaks)

Related

• Prior investigation: [Investigation] Netty ByteBuf leak in PerPartitionCircuitBreakerE2ETests with HTTP/2 transport - Handler added to wrong channel level #47290 (closed — different approach, identified handler placement issue but didn't fix the application-layer drain)

[Copilot]

Pull request overview

Fixes a Netty ByteBuf leak in the Cosmos fault-injection layer when simulating gateway response delays under HTTP/2, by ensuring the real response body is drained/released even when the response is discarded or dropped on cancellation.

Changes:

• Drain and release the response body before delaying when the injected delay exceeds the effective response timeout.
• Release the response body when delayElement discards a buffered HttpResponse due to downstream cancellation (via doOnDiscard).
• Add a helper (releaseResponseBody) to centralize the drain/release logic.

[jeet1995]

/azp run java - cosmos - tests

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[FabianMeiswinkel]

LGTM