Stop treating context errors as network errors where possible.

[benjirewis]

GODRIVER-2468
GODRIVER-1965

Stops returning a network error when minimum RTT exceeds time remaining until deadline. Stops checking for context expiration in writeWireMessage and readWireMessage; removes associated tests. Stops checking for context expiration in WithTransaction. Starts checking for any context error before running roundTrip in Execute (including cancelation). Adds tests to ensure that Execute does not mark done contexts with the TransientTransactionError label.

Network errors can be marked with the TransientTransactionError label here, and can therefore be retryable. Context errors do not represent retryable scenarios, so we should stop calling networkError() on context errors where possible. Once we stop treating context errors as retryable, we no longer need to check explicitly for them in WithTransaction.

[kevinAlbs]

Nicely done. This is tricky.

[kevinAlbs]

Aside: Is there a standard term to describe when a context returns a non-nil error on Err? I sometimes read "context expiration" to mean the deadline expired or timeout has elapsed.

https://pkg.go.dev/context describes:

// WithCancel arranges for Done to be closed when cancel is called;
// WithDeadline arranges for Done to be closed when the deadline
// expires; WithTimeout arranges for Done to be closed when the timeout
// elapses.

[benjirewis]

@kevinAlbs great question. I should not have used the term "context expiration". Err returns a non-nil error when the Done channel has been closed. The error message will explain why the channel was closed, which will either be context.DeadlineExceeded or context.Canceled. The more generic term is probably "context error", as "context expiration" seems to reference context.DeadlineExceeded.

[matthewdale]

Looks good 👍

You may want to add one of the GODRIVER tickets to the PR title to get the Jira integration (will make the next patch release easier because a ticket will have the automated commit messages).

[benjirewis]

@matthewdale was planning on putting the ticket names in the body of the commit message as outlined in the onboarding doc. Jira should still pick them up.