fix(multipooler): reset role/session_authorization on connection recycle

[haritabh17]

Problem

When a pooled connection has SET ROLE or SET SESSION AUTHORIZATION applied via ApplySettings, these GUCs persist on the PG backend after the connection is returned to the pool. PostgreSQL marks both with GUC_NO_RESET_ALL, so RESET ALL alone doesn't clear them.

If the role is subsequently dropped by another concurrent session, the next user of that pooled connection gets ERROR: role NNN was concurrently dropped from PG's shdepLockAndCheckObject during DDL operations.

Root Cause

1. SET ROLE / SET SESSION AUTHORIZATION tracked in multigateway SessionSettings, applied lazily via set_config() in ApplySettings
2. When recycled, PG backend retains the role/session_auth (GUC_NO_RESET_ALL)
3. ResetAllSettings only fires when connSettings != settings — if the next checkout matches the same *Settings pointer, no reset occurs
4. A concurrent DROP ROLE causes the stale connection to fail

Fix

Add ResetRoleState() on regular.Conn — called before conn.Recycle() in all executor paths:

• Checks if tracked settings include role or session_authorization
• If so: sends RESET ROLE; RESET SESSION AUTHORIZATION; RESET ALL to PG
• Clears tracked settings to nil (routes connection to pool.clean)
• Next checkout re-applies full desired settings via ApplySettings

Important: Settings objects are cached and shared via SettingsCache — we must not mutate Vars map. Instead we clear the connection's tracked settings pointer to nil.

Testing

pgregress results:

• Role-dropped errors: 464 → 0
• Passing tests: 122 → 123 (no regressions, gained maintain_every)