[mutianf]

SessionPoolImpl previously ran a recurring pool-level Watchdog on Client.sessionTimer that was only stopped inside awaitTerminated(), so callers that closed a pool without calling awaitTerminated() (such as TableBase.close() on cache eviction in compat.Util.createSessionMap) leaked the self-rescheduling watchdog task.

Remove SessionPoolImpl.Watchdog and instead arm a one-shot closeTimeout (CLOSE_SESSION_TIMEOUT = 5 minutes) on SessionImpl when entering WAIT_SERVER_CLOSE in startGracefulClose(), cancelled in updateState() as soon as the session leaves WAIT_SERVER_CLOSE (matching how openTimeout and heartbeatTimeout are managed per session). Also guard onSessionGoAway() against creating replacement sessions after the pool is closed.

[gemini-code-assist]

Code Review

This pull request ensures that the watchdog timer is closed when the session pool is closed and all sessions have drained, preventing potential timer leaks when callers only invoke close() without calling awaitTerminated(). A new test is added to verify this behavior. The review feedback suggests using System.nanoTime() instead of System.currentTimeMillis() in the test's wait loop to ensure monotonic time measurements and avoid sensitivity to system clock adjustments.

[gemini-code-assist]

Using System.currentTimeMillis() to measure deadlines or elapsed time is sensitive to system clock adjustments (such as NTP updates). It is safer and more robust to use System.nanoTime() for monotonic time measurements in test wait loops.

Suggested change

	long deadlineMs = System.currentTimeMillis() + 10_000;
	while (!sessionPool.watchdog.isClosed() && System.currentTimeMillis() < deadlineMs) {
	Thread.sleep(10);
	}
	long deadlineNano = System.nanoTime() + TimeUnit.SECONDS.toNanos(10);
	while (!sessionPool.watchdog.isClosed() && System.nanoTime() < deadlineNano) {
	Thread.sleep(10);
	}