Fix pre-commit linter errors (#1808)

Author: alcaeus

source/client-side-encryption/tests/README.md

@@ -251,7 +251,6 @@ Then for each element in `tests`:
                 This MAY be configured system-wide.
             - `tlsCertificateKeyFile` (or equivalent) set to
                 [drivers-evergreen-tools/.evergreen/x509gen/client.pem](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/x509gen/client.pem).
-                
 
             The method of passing TLS options for KMIP TLS connections is driver dependent.
     2. If `autoEncryptOpts` does not include `keyVaultNamespace`, default it to `keyvault.datakeys`.
@@ -427,7 +426,6 @@ First, perform the setup.
         This MAY be configured system-wide.
     - `tlsCertificateKeyFile` (or equivalent) set to
         [drivers-evergreen-tools/.evergreen/x509gen/client.pem](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/x509gen/client.pem).
-        
 
     The method of passing TLS options for KMIP TLS connections is driver dependent.
 
@@ -684,7 +682,6 @@ binary subtype 4 (or standard UUID), which MUST be decoded and encoded as subtyp
         This MAY be configured system-wide.
     - `tlsCertificateKeyFile` (or equivalent) set to
         [drivers-evergreen-tools/.evergreen/x509gen/client.pem](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/x509gen/client.pem).
-        
 
     The method of passing TLS options for KMIP TLS connections is driver dependent.
 
@@ -1447,7 +1444,6 @@ Four mock KMS server processes must be running:
 
 1. The mock
     [KMS HTTP server](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/csfle/kms_http_server.py).
-    
 
     Run on port 9000 with
     [ca.pem](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/x509gen/ca.pem) as a CA
@@ -1463,7 +1459,6 @@ Four mock KMS server processes must be running:
 
 2. The mock
     [KMS HTTP server](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/csfle/kms_http_server.py).
-    
 
     Run on port 9001 with
     [ca.pem](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/x509gen/ca.pem) as a CA
@@ -1479,7 +1474,6 @@ Four mock KMS server processes must be running:
 
 3. The mock
     [KMS HTTP server](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/csfle/kms_http_server.py).
-    
 
     Run on port 9002 with
     [ca.pem](https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/.evergreen/x509gen/ca.pem) as a CA

source/extended-json/extended-json.md

@@ -722,7 +722,6 @@ parsed as a normal document and not reported as an error.
 
     - Changed BSON binary type wrapper to
         `{"$binary": {"base64": <base64-encoded payload as a *string*>, "subType": <BSON binary type as a one- or two-character *hex string*>}}`
-        
 
     - Added "Restrictions and limitations" section.
 

source/retryable-writes/retryable-writes.md

@@ -314,7 +314,6 @@ Drivers MUST then retry the operation as many times as necessary until any one o
 
 - CSOT is enabled and the operation times out per
     [Client Side Operations Timeout: Retryability](../client-side-operations-timeout/client-side-operations-timeout.md#retryability).
-    
 
 - CSOT is not enabled and one retry was attempted.
 

source/server-discovery-and-monitoring/server-discovery-and-monitoring.md

@@ -240,7 +240,6 @@ Fields:
     Default null. (Only mongos and shard servers record this field when monitoring config servers as replica sets, at
     least until
     [drivers allow applications to use readConcern "afterOptime".](../max-staleness/max-staleness.md#future-feature-to-support-readconcern-afteroptime))
-    
 
 - (=) `type`: a [ServerType](#servertype) enum value. Default Unknown.
 

source/server-discovery-and-monitoring/server-monitoring.md

@@ -501,7 +501,6 @@ the client MUST follow these steps:
     [Why synchronize clearing a server's pool with updating the topology?](server-discovery-and-monitoring.md#why-synchronize-clearing-a-servers-pool-with-updating-the-topology)).
     If this was a network timeout error, then the pool MUST be cleared with interruptInUseConnections = true (see
     [Why does the pool need to support closing in use connections as part of its clear logic?](../connection-monitoring-and-pooling/connection-monitoring-and-pooling.md#why-does-the-pool-need-to-support-interrupting-in-use-connections-as-part-of-its-clear-logic))
-    
 
 4. If this was a network error and the server was in a known state before the error, the client MUST NOT sleep and MUST
     begin the next check immediately. (See

source/transactions-convenient-api/transactions-convenient-api.md

@@ -142,7 +142,6 @@ This method should perform the following sequence of actions:
         MaxTimeMSExpired and the elapsed time of `withTransaction` is less than 120 seconds, jump back to step eight.
         We will trust `commitTransaction` to apply a majority write concern on retry attempts (see:
         [Majority write concern is used when retrying commitTransaction](#majority-write-concern-is-used-when-retrying-committransaction)).
-        
 
     2. If the `commitTransaction` error includes a "TransientTransactionError" label and the elapsed time of
         `withTransaction` is less than 120 seconds, jump back to step two.

source/transactions/tests/legacy-test-format.md

@@ -182,7 +182,6 @@ Then for each element in `tests`:
 7. When testing against a sharded cluster run a `distinct` command on the newly created collection on all mongoses. For
     an explanation see,
     [Why do tests that run distinct sometimes fail with StaleDbVersion?](#why-do-tests-that-run-distinct-sometimes-fail-with-staledbversion)
-    
 
 8. If `failPoint` is specified, its value is a configureFailPoint command. Run the command on the admin database to
     enable the fail point.

source/unified-test-format/unified-test-format.md

@@ -1307,7 +1307,6 @@ The structure of each object is as follows:
     When `failureIsRedacted` is present and its value is `true`, the test runner MUST assert that a failure is present and
     that the failure has been redacted according to the rules defined for error redaction in the
     [command logging and monitoring specification](../command-logging-and-monitoring/command-logging-and-monitoring.md#security).
-    
 
     When `false`, the test runner MUST assert that a failure is present and that the failure has NOT been redacted.