As described in SERVER-46373, an aggregation pipeline may contain a stage which itself reads from a different collection from which the original command was run against. The remote requests for the sub-operation will generally fall into one of two buckets:

1. The targeted shard has already been contacted by mongos and already has knowledge of the transaction details. As long as the shard that's acting as a router correctly appends the txn information, then the recipient shard will respond to the query as if it was sent from mongos.
2. The targeted shard has not been contacted yet and thus has no knowledge of the transaction. In this case, the shard acting as a router needs to instruct the shard to start a new transaction. Currently mongos uses a startTransaction flag to achieve this. We could use a similar mechanism here, however blindly attaching the flag will not work due to the case described in (1) and there's a specific state machine that's expected for each participant.

Note that solving the above issue is half of the battle, as additional participants of the sub-operation need to be conveyed back to mongos to be used in the commit and readConcern enforcement.