[SQL] Add configurable retry attempts and backoff delay for JDBC connection establishment

[CodersAcademy006]

We ran into this at work — our ETL pipelines read from AWS RDS Postgres, and during RDS failovers (which last ~10-20s), every JDBC reader task would just blow up immediately because there's no retry on connection establishment.

For writers it's fine since you can wrap the write call in your own retry loop. But for readers the connection factory is baked into the RDD partition and you can't intercept it once the plan is materialized.

Looked through the JDBC internals and there's genuinely no retry/backoff anywhere in the connection path — JdbcDialect.createConnectionFactory calls ConnectionProvider.create and if that throws, the task dies.

What I did:

Added two new JDBC options:

• connectionRetryAttempts — how many times to retry (default 0, so existing behavior is unchanged)
• connectionRetryDelayMs — sleep between retries in ms (default 1000)

The retry logic lives in a new JdbcUtils.createConnectionFactory(dialect, options) wrapper rather than inside JdbcDialect.createConnectionFactory itself. This way custom dialect overrides still work and automatically get retry behavior on top.

Only retries on transient connection errors — specifically SQLTransientConnectionException or SQLException with SQLState class 08 (connection exception). Auth failures, bad queries, etc. fail immediately on the first attempt.

Also made sure the retry loop checks TaskContext.isInterrupted() before and after sleeping so task cancellation doesn't get blocked by the backoff delay.

Updated all call sites (JDBCRDD, JdbcRelationProvider, JdbcUtils.withConnection, JDBCWriteBuilder) to go through the wrapper.

Tests:

Added JDBCConnectionRetrySuite with tests for:

• normal connection (no retries)
• transient failure then success
• SQLState 08001 retry
• auth error (28000) — no retry, fails immediately
• exhausted retries — original exception preserved

Closes #58474.