TLDR: enforce expectations on partialTxnOps in OplogApplierImpl::_deriveOpsAndFillWriterVectors().

The function OplogApplierImpl::_deriveOpsAndFillWriterVectors() is used during oplog application to extract embedded operations from transaction oplog entries (ie. applyOps) from the current batch of operations returned from the oplog batching/fetching logic. The partialTxnOps map caches operations for multi-oplog transactions within the current batch - partial transaction operations outside the current batch in the large transaction is retrieved from the oplog collection in _addOplogChainOpsToWriterVectors().

The batch processing logic currently clears the cached partial transaction operations when it encounters an abort transaction oplog entry in the same batch. Per current rules around oplog batch boundaries, especially with regards to OplogBatch::mustProcessIndividually()|https://github.com/mongodb/mongo/blob/1947ddfa0a6418ea1aae5fa720ffb43aa4b3a4e1/src/mongo/db/repl/oplog_batcher.cpp#L132], an abort transaction oplog entry must be the only operation in any oplog batch.

It would be nice to clarify the logic in the oplog applier, preferably with an invariant on the expected state of partialTxnOps, when we attempt to process an abort for a prepared transaction.