GODRIVER-3473 Short-cicruit cursor.next() on invalid timeouts

[prestonvasquez]

GODRIVER-3473

Summary

Short-circuit calls to cursor.Next() where maxAwaitTimeMS >= operation timeout, which would result in socket timeouts.

Background & Motivation

The specifications assume that drivers iteratively apply the timeout provided at the constructor level (e.g., (*collection).Find) for tailable awaitData cursors:

If set, drivers MUST apply the timeoutMS option to the initial aggregate operation. Drivers MUST also apply the original timeoutMS value to each next call on the change stream but MUST NOT use it to derive a maxTimeMS field for getMore commands.

The Go Driver might decide to support the above behavior with DRIVERS-2722. The principal concern is that it would be unexpected for users to apply an operation-level timeout via contexts to a constructor and then have that timeout later be applied while working with a resulting cursor. Instead, it is more idiomatic to apply the timeout to the context passed to Next or TryNext.

[mongodb-drivers-pr-bot]

API Change Report

./v2/x/mongo/driver

compatible changes

(*BatchCursor).MaxAwaitTime: added

[matthewdale]

Looks good! 👍