Use Case

As a driver user using FindCursor.count(),
I expect that no sessions are leaked,
So that I do not have a resource leak in my application.

As a driver engineer or user,
I expect that cursors do not instantiate any resources that need to be cleaned up until the cursor is initialized,
So that I do not need to close an unused cursor just to clean up resources.

When no explicit sessions are provided, the AbstractCursor class instantiates a client session upon construction. This session is never cleaned up unless the cursor is closed. This means that the following code leaks a session:

const cursor = collection.find();

This is also true of any APIs on the cursor that execute different operations, such as cursor.count():

// cursor never iterated, leaked session
collection.find().count();

The sessions will be reclaimed when the client is closed, but we should not require users to close the client simply to clean up sessions.

User Experience

If the cursor is never iterated, the session will never be destroyed and will remain active in memory until the client is closed.

I believe this impacts shell, since shell supports `cursor.count()`.  My guess is that every shell find command returns a new cursor, so multiple cursor.counts() in a row would leak sessions.

Acceptance Criteria

• Defer session creation until cursor initialization (i.e., a `getMore` is being executed).

Testing AC

• When a cursor is instantiated but not iterated, no client session is allocated
• Q: can we use the resource leak tests to cover this scenario?

Documentation

• Expand the "close" section of the MongoDB manual to explain when close should and should not be called e.g., not necessary if cursor is exhausted)