CAMEL-24045: camel-sql - Fix connection leak with outputType=StreamList (backport to 4.18.x)

[Croway]

Backport of #24656 to camel-4.18.x.

JIRA: https://issues.apache.org/jira/browse/CAMEL-24045

SqlProducer.processStreamList() takes a raw connection from the DataSource so the result set can stay open while the exchange is routed. When PreparedStatement.execute() returns false (INSERT/UPDATE/DELETE/DDL), the result-set branch was skipped: no ResultSetIteratorCompletion was registered and neither the connection nor the statement was ever closed — the catch block only cleaned up on exception. Since the executed SQL can vary per exchange via the CamelSqlQuery header or useMessageBodyForSql=true, each such exchange leaked one pooled connection, eventually exhausting the pool.

Changes:

• Close the statement and return the connection to the pool when the executed statement produced no result set
• Set the CamelSqlUpdateCount header from getUpdateCount() for the non-query case, consistent with the non-query path in processInternal()
• New test with a connection-counting DataSource proving no connection stays open after the exchange completes and asserting the update-count header
• Adapted test import for camel-4.18.x (junit5 package instead of junit6)

Claude Code on behalf of Croway

🤖 Generated with Claude Code

[gnodet]

LGTM — clean backport of #24656 to 4.18.x.

The else branch in processStreamList() correctly closes the statement and connection
when ps.execute() returns false (non-query statement). Without it, the connection was
never returned to the pool since ResultSetIteratorCompletion was only registered for
query results. Also correctly sets the SQL_UPDATE_COUNT header for consistency with
processInternal().

The ConnectionCountingDataSource test wrapper using JDK Proxy is a nice approach — tracks
open/close atomically and asserts zero open connections after the exchange completes.

Note: test correctly uses junit5 import for the 4.18.x branch (vs junit6 on main).

Claude Code on behalf of gnodet