WIP feat(DRIVERS-3239): add exponential backoff in operation retry loop

[baileympearson]

Description

Summary of Changes

Notes for Reviewers

What is the motivation for this change?

Release Highlight

Release notes highlight

Double check the following

• Lint is passing (npm run check:lint)
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[baileympearson]

From the transactions spec:

The session transitions to the "transaction in progress" state after completing the first command within a transaction —
even on error.

Technically we weren't spec compliant - we transitioned a transaction to "in progress" here (in applySession), which is called when constructing the final command document. In practice, I think this is effectively the same thing: If we unconditionally transition a transaction into "in progress" after an operation finishes, transitioning the transaction to "in progress" has the same effect (so long as a transaction is not used concurrently, which they never are because transactions are not thread safe).

With client backpressure, we now need to omit RetryableErrors from transitioning transactions to in progress, because if we retry the first command in a transaction we must include startTransaction on the retry. This change, plus the change in updateSessionFromResponse handle this scenario.

[baileympearson]

edge case: if we encounter a network error (such as a failCommand with closeConnection=true) we never get a server response to update a session with, but still need to update the session's transaction, if the session is in a transaction.

[baileympearson]

better name imo.