Unlike multi-document transactions which can span through multiple applyOps oplog entries, batched writes should generate one and only one applyOps. We should also ignore the multi-doc transactions specific maxNumberOfTransactionOperationsInSingleOplogEntry parameter. The reason for both decision is that the applyOps entry for a batched write lacks the multi-doc transactions specific txnNumber field which is needed to make multiple applyOps entries replicate atomically. There's no known use case for batched writes requiring to generate more than a single applyOps (16MB worth of oplog).

Original title: Investigate core/multi_batched_deletes.js running with 'maxNumberOfTransactionOperationsInSingleOplogEntry'
Original description: maxNumberOfTransactionOperationsInSingleOplogEntry: 2 causes the test to fail. It appears the test runs with 'partialTxn': true when the oplog is dumped. We expected batched multi deletes to fail completely when run in a transaction. It is unclear why this server parameter would cause the test to run batched deletes in a transaction.