When external auth services experience downtime and/or slowness, the server is expected to handle this in a deterministic manner that may vary slightly depending on the specific external auth mech. For LDAP, we expect the following:

1. Connections that are already authenticated as LDAP users should remain authenticated indefinitely and remain authorized with their last-known cached privileges.
2. Connections that are not authenticated will be unable to authenticate as an LDAP user until the LDAP host is reachable again.
3. After an LDAP server comes back up, any changes to an LDAP user's group membership that affect MongoDB privileges should be reflected in the first operation the user performs after the server comes back up if the LDAP server was down for more than ldapUserCacheStalenessIntervalSeconds. Otherwise, it should be reflected within ldapUserCacheRefreshIntervalSeconds. If ldapShouldRefreshUserCacheEntries is false, then the changes should be reflected within ldapUserCacheInvalidationIntervalSeconds.
4. If an LDAP server is up but slow, then the server is expected to hang for up to ldapTimeoutMS milliseconds for a response. Binds and searches that take longer than this should result in authentication failures or Unauthorized failures on the operation but should not adversely affect the server.

To validate this behavior, an FSM will be created that randomly switches the mock LDAP server between the following states:

1. Normal (serving responses within a normal timeframe)
2. Referral (referring all requests to another LDAP server, with slightly increased latency)
3. Slow (hanging on all requests for a period of time ranging around the server's configured LDAP timeout)
4. Down (completely unresponsive)

Meanwhile, a 3-node MongoDB replica set will be set up and will run a standard workload (likely taken from our other tests). The clients will auth as LDAP users and attempt to perform various operations. Depending on the state of the mock LDAP server, the test will assert that clients always receive a response from the replica set within an expected period of time. The test will also assert that clients' authorization privileges are never stale beyond the aforementioned intervals.