Add remote address tracking for JDBC/Avatica SQL queries

[dprmfl]

Fixes #19230.

Description

remoteAddress is always null for JDBC/Avatica queries, even though it's a documented dimension for sqlQuery/time, sqlQuery/bytes, and sqlQuery/planningTimeMs. This PR fixes that.

Problem

See #19230. In short, remoteAddress was hardcoded as null in PreparedStatement.java and SqlStatementFactory.java for the Avatica path, while SqlResource.java (the HTTP path) correctly passes
httpRequest.getRemoteAddr().

Solution

1. DruidAvaticaJsonHandler — extracts remoteAddr from the HTTP request and stores it in a ThreadLocal. Cleans up in finally to prevent memory leaks.
2. DruidMeta — reads from ThreadLocal in openConnection() and injects remoteAddress into the connection context map.
3. SqlStatementFactory & PreparedStatement — reads remoteAddress from context and passes it to DirectStatement.
4. SqlExecutionReporter — emits remoteAddress as a dimension in metrics and includes it in request logs.

No changes to DruidConnection or any existing data structures —remoteAddress piggybacks on the context map that's already there.

Testing

Added three test methods to DruidAvaticaHandlerTest:

• testRemoteAddressInLogs — verifies remote address is captured for normal queries
• testRemoteAddressInFailedQuery — verifies remote address is captured even when queries fail
• testRemoteAddressInPreparedStatement — verifies remote address is captured for prepared statements

Release note

sqlQuery/time, sqlQuery/bytes, and sqlQuery/planningTimeMs metrics now include remoteAddress for JDBC/Avatica queries, consistent with the HTTP SQL API.

---

Key changed/added classes in this PR

• DruidAvaticaJsonHandler — ThreadLocal-based remote address capture
• DruidMeta — connection context enrichment with remote address
• SqlStatementFactory — remote address extraction and propagation
• PreparedStatement — remote address handling for prepared statements
• SqlExecutionReporter — remote address emission in metrics and logs

---

This PR has:

• been self-reviewed.
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.