This is to handle the case where the external client retries retryable writes that are being executed using internal transactions. This is from the design:

To support such retries but avoid executing write statements within a retryable internal transaction more than once, upon seeing a startTransaction statement for a new internal transaction, a transaction participant will also check if there is an existing in-progress internal transaction for the write command that the new transaction corresponds to. If there is, it will throw a RetryableTransactionInProgress error. The error will be caught and cause the startTransaction statement to block until the existing transaction commits or aborts. If the existing transaction commits, a RetryableTransactionCommitted error will be thrown and the mongos will retry the transaction (with the original txnRetryCounter) to retrieve the original response. If the existing transaction aborts, a NoSuchTransaction will be thrown and the mongos will retry the transaction (with a higher txnRetryCounter).