We need to test the error propagation behavior in case of sharded transaction failures caused by rejections by the ingress operation rate limiter, for the following cases:

• one of the participants rejects an a prepare command in the transaction
• one of the participants rejects an operation in the transaction
• one of the participants rejects a commit
• one of the participants rejects an abort
• the coordinator rejects a request from mongos (commit/abort)

We should cover both the budget exhaustion and retry cap scenarios.

Given the Sharding-Fixed executor can be exempt from rate limiting, we must ensure the commit for sharded transactions is exempt from being rate limited. The CRUDs themselves within the transaction are subject to being rate limited by the IRRL.