Large transactions will pack multiple operations into a single applyOps. The caller of OpObserver::onTransactionPrepare() won't know how many oplog slots are needed in advance. To avoid the bug in SERVER-35798, we still need to reserve an oplog slot in TransactionParticipant to prevent advancing lastApplied and prevent secondaries to read the prepare oplog entry before the transaction is actually prepared. OpObserverImpl can reserve and use its own OplogSlots to write packed oplog entries in side transactions. The prepare timestamp can be set by OpObserver or by TransactionParticipant with the getLastOp() on ReplClientInfo.

An alternative solution is to reserve more oplog slots than needed, e.g. one for each operations, but the first proposal imposes less restrictions on the caller and simplifies the OpObserver interface.