This should change OplogBatcher::mustProcessIndividually so that prepare entries will no longer be required to be in their own batch. The commitTransaction/abortTransaction command will no longer be required to be in its own batch, if and only if that commitTransaction/abortTransaction refers to a session in the SplitPrepareSessionManager.

Note that currently OplogBatcher::mustProcessIndividually is the same for both secondary mode and initial sync/recovering mode. We should probably do the above only for secondary mode and keep the initial sync/recovering behavior.

Note: We decided to still have every commitTransaction/abortTransaction entry to be processed in its own batch. This is because:

1) Since we currently disallow a session to be split if it was already split and not yet released. This could be relaxed so that multiple splits on the same session are allowed as long as they refer to different txnNumbers, but before we do that, the following case can happen if we allow commits/aborts to be in the same batch with others:

• batch 1: [prepare(sess1, txn1)]
• batch 2: [commit(sess1, txn1), prepare(sess1, txn2)] 

When trying to split the second prepare, it fails due to this limitation since we only release the split sessions after the txn is committed and the batch is finished.

2) Allowing commits/aborts to be in the same batch with other ops makes it possible for more edge cases and requires more testings. And since applying a commitTransaction/abortTransaction entry is usually quick, we think it's fine to first disallow this and once we're confident that the new algorithm works fine, we can start an effort to optimize it.