A few risks associated with this work:

1. Our "connection checkout timeout" (ConnectionPoolSettings.getMaxWaitTime) is documented as "The maximum time that a thread may wait for a connection to become available." However, it is not clear what is meant here by "available". Do we mean available for executing a user-requested operation, or do we mean "available" as in "there are no connections available for the pool to either provide or create"? Our implementation (and, highly likely, all other drivers) uses the second interpretation, i.e., the actual checkout duration is not limited by ConnectionPoolSettings.getMaxWaitTime, because opening a connection is not limited by it, and opening a connection includes handshaking, which in turn, includes authenticating. The latter may take up to about 5 minutes as a result of this work (this was in principle possible even before the work). If authentication takes significant time, this behavior has a chance to surprise our users.
2. We have Authenticator.authenticateAsync for implementing asynchronous authentication for the reactive API. However, we use synchronous SalsClient underneath, which is blocking in case of the GSSAPIAuthenticator, and will be blocking (up to about 5 minutes) in the OIDC authenticator. The team has discussed this and decided that we will continue doing blocking auth-related actions when implementing the reactive driver API until someone complaints. If that happens, we may always convert a blocking synchronous API into an asynchronous one by executing the blocking auth-related methods in a single (per MongoClient) internal dedicated thread, as long as those methods don't need to be called concurrently with each other by a single MongoClient (the methods we identified don't need to be called concurrently).