GEOMESA-3583 Trino datastore: pool JDBC connections by unique authorization set

[cwdobbins]

Trino datastore: pool JDBC connections keyed by authorization set

Closes #3583 (deferred from #3573).

Problem

The Trino datastore forwards each caller's authorizations to Trino as an
extraCredentials entry that is fixed on the connection at creation — a
connection is its authorization context. The initial implementation therefore
opened a fresh connection per query, so deployments could never reuse
connections across requests, paying the connection setup cost on every query.

Approach

Connections are now pooled, keyed by the normalized authorization set
(sorted, deduped, validated): requests with the same effective auths reuse
connections; requests with different auths structurally cannot share one.

• ConnectionPool — wraps a commons-pool2 GenericKeyedObjectPool.
• PooledConnection — a dbcp2 DelegatingConnection subclass whose
  close() returns the delegate to the pool exactly once; callers keep
  ordinary try-with-resources semantics and no call sites changed. Any
  other use after close throws, and passivate() closes straggler statements
  before the connection is re-lent.
• The same normalized list feeds both the pool key and the credential
  encoding, so a pooled connection's credential always matches its key.
  TrinoDataStore.dispose() drains the pool.

New dependencies

commons-pool2 and commons-dbcp2- Deployments that stage this module's
JAR directly onto a classpath must stage these alongside it.