inconsistent treatment of applyOps during secondary oplog application

We started batching applyOps oplog entries with CRUD operations in SERVER-32913 and unpacking the embedded CRUD operations within the applyOps command for the writer threads to apply during the oplog application process. However, the unpacking is done only on storage engines that support document level concurrency. This penalizes the performance of the CRUD operations in the same batch when we run the applyOps command logic under the global write lock. We should either:

• unpack the applyOps CRUD operations under all storage engines; or
• batch applyOps with other CRUD ops when the storage engine supports document level concurrency.