In SERVER-110003, we changed the "state" from a set of unrelated boolean values to a mutually exclusive enum, as this models the state better. However, we inadvertently allowed for a state transition from kFailed to kExpired if we detected that the pool became expired. Normally this would be okay and the pool would just be delisted, but due to the way ShardingTaskExecutorPoolController is implemented, the pool is only allowed to be shut down if every pool the "group" (i.e. replica set) is also expired. If the controller doesn't allow the pool to be delisted, it'll proceed to spawnConnections to attempt to establish a new connection. This loop will repeat endlessly because _lastActiveTime will only be updated when something tries to get a connection, but all this is happening in the background to satisfy minPoolSize. I was able to repro this by forcing the LimitController (used in the C++ tests) to always return false for canShutdown. By forbidding a transition out of kFailed to kExpired, it solves the problem.

To ensure we can still expire even if the pool is currently failed, we may want to track expiration separately from the main state of the pool, similar to the pre-SERVER-110003 behavior.