Fixed - connection with an unanswered command after a response timeout is reused first by retries and new commands - #7375

Fixes #7373

Problem

With the LIFO pool (since 3.52.0), a connection released after a response timeout goes back to the head of the free deque. The retry and new commands then poll the same connection and are pipelined behind the timed-out command, which stays in the channel's COMMANDS_QUEUE until its reply arrives.

Change

• ConnectionsHolder.releaseConnection() releases a connection that still has unanswered commands to the tail of the free deque.
• Healthy connections are still released to the head, so LIFO and idle-discard (Connection selection algorithm to minimize number of connections needed #5151) are unchanged.
• The stalled connection is not closed. It is handed out only if no other free connection is available.
• Added RedisConnection.hasPendingCommands().
• Shared connections (usage > 1) and the pubsub pool keep the current behaviour.

Tests

• ConnectionsHolderTest: covers release to the tail, LIFO for healthy connections, shared connections, and fallback when only one connection is free.
• RedissonTest.testStalledConnectionIsNotReusedAfterResponseTimeout: WAIT exceeds the response timeout on one connection, then an immediate GET follows. Before this change the GET times out on the same channel; with it, the GET succeeds.