Check SQL refresh throttle before discarding the connection pool

[SwaroopKolasani]

What changed?

Check the SQL session refresh throttle before discarding the current connection pool.

Previously, a forced refresh cleared and closed the active pool before checking whether the refresh was throttled. If throttled, no replacement pool was created and the database handle was temporarily left without a connection pool.

The current pool is now preserved when the refresh is rejected by the throttle.

Why?

This addresses the refresh-ordering failure mode described in #11691.

It does not address stale errors from an older connection pool triggering refresh of a newer pool; that requires separate generation-aware handling.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

Added a deterministic regression test using the existing fake clock and SQL connector. The test verifies that a throttled forced reconnect:

• does not create another pool
• keeps the currently installed pool intact

Validated with:

go test ./common/persistence/sql/sqlplugin/... -count=1

go test -race ./common/persistence/sql/sqlplugin/ -run 'TestDatabaseHandle' -count=1

go vet ./common/persistence/sql/sqlplugin/