Use Case

Some driver APIs create and iterate cursors internally.  These APIs must:

• govern the lifetime of the cursor with the shared timeoutMS
• refresh the timeout to the total timeoutMS for the parent operation

If cursors are instantiated with the remainingTimeoutMS as the timeoutMS value for the cursor's lifetime, the timeout will be refreshed to `remainingTimeoutMS`, not `timeoutMS` when refreshing the timeout for a killCursors.

User Experience

• What is the desired/expected outcome for the user once this ticket is implemented?
• If bug: What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?

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

• Allow cursors to accept a timeoutContext as an option.  If provided, cursors will use the provided context as their timeout context.
• Throw an error if the timeoutContext is provided and the timeoutMode is not LIFETIME.
• Throw an error if the cursor is rewound with an external timeout context.

Testing Requirements

• unit test, spec test sync, etc

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