The Node driver currently determines eligibility for retryable writes using the `ServerDescription` associated with a server.  This description is updated after each successful monitoring check.  However, relying on the `ServerDescription` to determine retry eligibility can lead to race conditions (see the linked cdriver ticket).

Retryability should be determined by the initial handshake for each connection.  We currently store this data on the `StreamDescription` class but have no mechanism to access this information when we determine whether or not to retry an operation (in execute_operation).

This most likely requires a design.

Some thoughts

• If in our connection layer, we conditionally attach retryable writes labels depending on server eligibility, then our operations layer could solely rely on the presence of a retryable writes label when determining whether or not to retry.
• We could propagate the handshake information necessary to determine retryability up to the operations layer on errors.  Minor code changes most likely, but attaching extra information to errors purely to communicate between parts of the driver feels like a bad design choice.
• We could consider a "retryabiliity context" or "operation context" abstraction that could live throughout the lifecycle of an operation at all layers.  This abstraction could be used to communicate between layers of the driver.  c# has a similar abstraction (here).

Related Driver tickets: DRIVERS-1262 & DRIVERS-746