WebSocket: a reset of either joined socket is logged at ERROR by ConnectionBase #157

Version

5.2.1 (also current main)

Context

Once the backend answers 101, ReverseProxy.Proxy#sendResponse joins the client socket
(request.proxiedRequest().toNetSocket()) and the backend socket (proxiedResponse.netSocket()) with handler and
closeHandler only. Neither socket gets an exception handler, so a failure on a joined socket is logged as an error.
The common case is a peer resetting its connection, which is routine for WebSockets (a closed tab, a mobile client
changing networks, a load balancer in front of the proxy closing its connection with a reset). With the native epoll
transport each one logs:

[ERROR] io.vertx.core.net.impl.ConnectionBase - recvAddress(..) failed with error(-104): Connection reset by peer

(Connection reset with the NIO transport.) Behind HAProxy this is a steady stream of ERROR lines, one per abruptly
ended WebSocket, that cannot be told apart from real failures.

Client side. toNetSocket() replaces the HTTP server connection with a new NetSocketImpl
(Http1ServerConnection#netSocket). The new connection does not keep the server's exception handler (which logs
connection failures at trace by default), so a reset takes this path:

1. the read fails with ECONNRESET, and Netty fires exceptionCaught and then closes the channel;
2. VertxHandler#exceptionCaught calls ConnectionBase#handleException on the NetSocketImpl;
3. ConnectionBase#handleException finds no exception handler and logs the exception at ERROR;
4. the channel closes, closeHandler fires and closes the backend socket.

Backend side. proxiedResponse.netSocket() is an HttpNetSocket over the request to the backend. A failure is
reported to that request's connection (Http1ClientConnection#handleException, which calls
ConnectionBase#handleException) and to the request (HttpClientRequestImpl#handleException), each of which logs it
at ERROR unless it has an exception handler, and then to the socket. The request and its connection belong to
whoever created the request (the OriginRequestProvider), so this issue only covers the joined sockets. Related: the
request also logs Connection was closed at ERROR whenever the proxy closes a WebSocket, a normal close included,
unless its creator sets an exception handler (the existing WebSocketTest tests log it on main).

The failure branch right below (Handle this case printed to System.err when toNetSocket() fails) is covered by
#155 / #156.

Steps to reproduce

1. Proxy a WebSocket to a backend and let the backend answer 101.
2. Once data has gone through the proxy, reset the client connection (close it with SO_LINGER 0).
3. The proxy logs the reset at ERROR from io.vertx.core.net.impl.ConnectionBase.

Possible fix

Set an exception handler on both joined sockets, next to the closeHandlers, that logs at trace and closes the other
socket.

Do you have a reproducer?

The steps above; there is no test with the fix, because the change only affects what is logged. After an
IOException on a read, Netty closes the channel once it has reported the exception, and the existing closeHandlers
then close the other socket, so both sides close with or without the exception handlers. A test would have to capture
Vert.x's own log output, which nothing in this project does, and would depend on which logging backend the tests
happen to run with.