After a secondary splits and applies a prepared transaction, it can step up to be a primary. In that case we will need to eventually commit the transaction while it has been split. Primary needs to check if the transaction to commit has been split and take the following actions if so:

"Committing a split transaction on a primary requires special care to ensure that the operation is atomic in case of failure.  We will take an IX lock on the RSTL, and we will reserve an oplog slot for the commit prior to attempting to commit any of the split transactions.  We will loop through the splits, set the session/transaction information on the opCtx to each split, and commit each split (commitPreparedTransaction) through the TransactionParticipant in an UnreplicatedWritesBlock.  This will cause the splits to commit as if they are on a secondary with no oplog writes.  When this is complete we will restore the original session/transaction information and call commitPreparedTransaction on the top level transaction, passing in the reserved optime.  The TransactionParticipant normally rejects commits with reserved optimes on primary, but if the participant is in "splitPrepare" state, it will accept only such commits.  It will skip actually trying to commit the transaction (because no transaction exists), but will write the commit oplog entry (which will update the transaction table) and update statistics as normal.  Any failure in this process after reserving the optime must crash the server."

Note that normally when calling CommitTransaction on the transactionParticipant, the session is already checked out, but in the split case, only the top-level session will be checked out before calling CommitTransaction on the transactionParticipant, so we need to manually checkout the split sessions when committing the splits.

This ticket handles commits for split transactions, while SERVER-72745 will add handling for aborts.