Flush pending writes before closing the connection on caught exceptions

[asalajan]

Fixes #6155

Motivation:

When an exception is caught on a connection, VertxHandler#exceptionCaught dispatches the throwable to the user handlers and then closes the channel with chctx.close(). A response written from the handler -- for instance a 400 written from request().exceptionHandler() when HttpContentDecompressor throws a DecoderException on a malformed compressed body -- is enqueued in the outbound message queue but not flushed, because VertxConnection#write skips the flush while a read is in progress. chctx.close() then causes Netty to discard the unflushed entries from the ChannelOutboundBuffer, so the response never reaches the client: the client observes a connection reset instead of the intended HTTP response.

Changes:

Route the exception-driven close through the channel so it traverses the pipeline tail and invokes VertxHandler#close -> VertxConnection#writeClose, which flushes pending writes (an empty buffer with forceFlush=true) and closes the channel only once the flush has completed. This is the same flush-then-close path already used by graceful shutdown, idle close and the regular close(); the exception path simply was not using it. The bare chctx.close() is kept as a fallback for the case where no connection has been set yet (handlerAdded has not run), since VertxHandler#close dereferences it.

Add a regression test, Http1xTest#testRequestDecompressionInvalidBodyDeliversErrorResponse, that sends a malformed gzip body to a server with decompression enabled and asserts the client receives the response written from the request exception handler.

HTTP/2 is unaffected: its codec replaces VertxHandler in the pipeline, so connection-level exceptions do not go through this path.

I'm happy to open the backport PRs for version 5.0.x and 5.1.x once this one is reviewed/merged

Developed with assistance from an AI coding agent (Claude Code). I reviewed and tested the changes.

[vietj]

for this fix we need a test in VertxConnectionTest that reproduces the situation as well.

[asalajan]

for this fix we need a test in VertxConnectionTest that reproduces the situation as well.

I have added testFlushPendingWriteOnExceptionClose() in VertxConnectionTest