Use Case

As an... auto-connect user
I want... the MongoClient to run my operation as soon as it's able (according to the operation's read preference) and without running unnecessary steps such as blocking on primary discovery (or whatever is configured by the global client read preference)
So that... the initial client start up experience is as efficient as possible

Ex. I would expect the following snippet to only performs a nearest selection. Does not run a handshake for the auth (since the find covers it) does not a server selection for the client-level ReadPreference setting

const client = new MongoClient('mongodb://user:pass@localhost:27017');
// no explicit call to .connect()
const doc = await client
  .db('test')
  .collection('test')
  .findOne({}, { readPreference: 'secondary' });

User Experience

• The user observed difference is that connect blocks on primary selection can be surprising when you expect to be able to launch a client and perform a find against something other than the primary.

This can be surprising if a user is expecting an auto connecting to "just work" whenever they want to contact a topology where they don't need to wait for primary.

Dependencies

• upstream and/or downstream requirements and timelines to bear in mind

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
• Is there an opportunity for better cross-driver alignment or testing in this area?
• Is there an opportunity to improve existing documentation on this subject?

Acceptance Criteria

Implementation Requirements

• Move the server selection step into the __skipPingOnConnect condition so we don't perform a server selection when auto-connecting (since we will server select for the command)

Testing Requirements

• Check that server selection is not doubled for auto-connect

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc
• if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward