Refer to the notes in the design doc.

AC:

• CMAP test runner updates:
  • unskip tests
  • add handling for appName,
  • implement ready test operation,
  • implement timeout parameter in waitForEvent
  • Note that a minPoolSize frequency check requirement was added then later removed in the spec, refer to the latest spec for the current wording
• CMAP implementation updates:
  • new “state” property on the pool: “paused”, “ready”, “closed”
    • closed is a final state
    • ready can be set via the ready() method if the pool is paused
    • paused is the initial state as well as the state after clear() is called; while the pool is paused, connections cannot be checked out or established
  • API changes:
    • new PoolReadyEvent interface
      • has an address property
    • new PoolClearedError interface
      • the pool paused error, which must be a non-timeout network error when it occurs during checkout
    • new ready() method that transitions pool into “ready” state and emits PoolReadyEvent
    • update the checkOut() method to throw an error if the pool is paused (in addition to when it’s closed): PoolClearedError
      • emit ConnectionCheckOutFailedEvent with reason=“connectionError”
    • update the clear() method to clear the waitqueue and mark the pool as paused (in addition to marking all current connections as stale)
      • if a pool is already paused when it is cleared, it must NOT emit a PoolClearedEvent, but the generation should still be incremented
      • requests in the WaitQueue must proactively fail with errors indicating that the pool was cleared while checkout was being performed
      • Per NODE-3657, the clear method modifications described above must NOT apply in LB mode; in LB mode, clearing the pool does NOT transition the pool to paused and does NOT clear the waitqueue
      • In LB mode, the pool MUST still emit a PoolClearedEvent after incrementing the generation
    • update the close() method to transition the pool to "closed" state
  • Behavioral changes:
    • pool must be initialized in paused state and cannot start populating minPoolSize until it is marked ready
    • pool will be marked ready by SDAM after successful server checks, at which point the minpoolsize population can start and the new PoolReadyEvent should be emitted
    • errors during pool population must be handled via SDAM machinery (see Application Errors section and cross reference SDAM spec); if not possible, the pool MUST be cleared
      • see updated algorithm for populating connection
• SDAM implementation updates:
  • authentication errors should result in the pool being cleared in addition to marking the server unknown (the latter is already implemented)
  • when server transitions from unknown to data bearing or direct connection (see NODE-3349), driver must ensure connection pool is set up and marked “ready”
    • refer to the updated algorithm onServerDescriptionChanged for marking pool ready
  • clearing the connection pool for a server must be synchronized with the update to ServerDescription
    • refer to the updated handleStateChangeError algorithm
• Server monitoring implementation updates:
  • successful check against a server should mark pool as ready (the server should not be able to be selected if its pool is still paused)
  • on error during server check, clearing the pool must be synchronized with marking the server Unknown
  • see updated monitor run() command
• SDAM Testing updates:
  • new SDAM CMAP prose test
  • SDAM automated test updates and new test already synced but need to be unskipped (specifically, integration/minPoolSize-error)
• once everything is done, close NODE-3657 and NODE-3258
  • NODE-3657 exists for LB mode clarifications
  • NODE-3258 clarifies that PoolReadyEvent MUST be emitted before background thread can resume creating connections