The original motivation for adding the readOnly value `kOutstandingAdditionalParticipant` to the TransactionRouter was to prevent ever choosing a read-optimized commit path in the event an additional participant did a write on a getMore request, but the shard that added the participant responded back to the parent router before hearing of the write. Today, we don't actually allow writes in transactions in getMores, so this was an extra layer of protection - SERVER-88515 made it so that the getMore command will fatally fail if a write is done while in a transaction, so the special readOnly value and handling in the transaction router isn't necessary.