The changes from 7854fa3 as part of SERVER-87558 introduce a new state Participant::ReadOnly::kOutstandingAdditionalParticipant within the TransactionRouter to allow the top-level router to learn a participant has been added to the transaction but it is not yet known whether the transaction participant has only done reads or has also done writes. SERVER-89275 represents a bug which was introduced thereafter by allow the outstanding participant to be chosen as the recovery shard. This was unsafe if the outstanding participant had only done reads and another shard had done writes because the outstanding participant wouldn't durably be able to recover the commit xor abort decision. SERVER-89806 is removing the Participant::ReadOnly::kOutstandingAdditionalParticipant state and instead relying on the work from SERVER-88515 that a getMore command cannot do a write inside of a multi-statement transaction.

Given that eventually other commands and operations may be permitted to run in multi-statement transactions in the future, we should generalize the safety check added to the getMore command by moving it into the prepareTransaction command itself. The idea would be for the prepareTransaction command to ensure any participant in the Participant::ReadOnly::kOutstandingAdditionalParticipant state is reported to the transaction coordinator (and durably written as part of persisting the participant list) and an additional parameter is included in the prepareTransaction command for all participants in the Participant::ReadOnly::kOutstandingAdditionalParticipant state requiring their storage transactions have done no writes before responding ok:1.