DRIVERS-1641: pre-4.4 mongos writeConcernError does not determine ret…

…ryability

Also clarify that pre-4.4 writeErrors[].code should never be used to determine retryability. This is intentionally untested because failCommand does not provide a way to mock writeErrors.

source/retryable-writes/retryable-writes.rst

@@ -252,7 +252,8 @@ The RetryableWriteError label might be added to an error in a variety of ways:
  errors that meet the following criteria if the retryWrites option is set to
  true on the client performing the relevant operation:
 
- - a server error response with any the following codes:
+ - a mongod or mongos response with any the following error codes in the
+ top-level ``code`` field:
 
  .. list-table::
  :header-rows: 1
@@ -284,8 +285,14 @@ The RetryableWriteError label might be added to an error in a variety of ways:
  * - ExceededTimeLimit
  - 262
 
- - a server response with a write concern error response containing any of the
- previously listed codes
+ - a mongod response with any of the previously listed codes in the
+ ``writeConcernError.code`` field.
+
+ Drivers MUST NOT add a RetryableWriteError label based on the following:
+
+ - any ``writeErrors[].code` fields in a mongod or mongos response
+
+ - the ``writeConcernError.code`` field in a mongos response
 
  The criteria for retryable errors is similar to the discussion in the SDAM
  spec's section on `Error Handling`_, but includes additional error codes. See
@@ -850,6 +857,9 @@ inconsistent with the server and potentially confusing to developers.
 Changelog
 =========
 
+:2024-01-02: Do not use ``writeConcernError.code`` in pre-4.4 mongos response to
+ determine retryability. Do not use ``writeErrors[].code`` in
+ pre-4.4 server responses to determine retryability.
 :2023-12-06: Clarify that writes are not retried within transactions.
 :2023-10-02: When CSOT is not enabled, one retry attempt occurs.
 :2023-08-26: Require that in a sharded cluster the server on which the