Missing op.Data when alterations to same ns + id happen within same Timestamp Epoch second about gtm

[rwynn]

@zph, thanks for adding this. At some point I realized that it would be possible for 2 or more updates on the same _id to be included in a single batch. My original concern was that the Data would be nil on all but one of them. I will also fix the concurrency issue where the Data is shared in memory between the ops.

[rwynn]

@zph, recently I added an optimization to gtm with regard to updates. Previously, all updates (when not using UpdateDataAsDelta) would go through the fetch path where the corresponding data would be retrieved and set on the op. Now, gtm distinguishes between different types of updates. Some updates replace the entire document and thus the oplog gets a full copy of the data. This is the case that was optimized to not cause a fetch but rather to simply use the data in the oplog. Other updates that use $set, $unset, $addToSet, etc are recorded in the oplog as $set and $unset deltas. In this case gtm will still use the fetch approach to get the full data.

In summary, updates like

db.test.update({_id: 1}, {foo: 2})

do less work now in gtm, where updates like

db.test.update({_id: 1}, {$set: {foo: 2}});

do the same amount of work as before this commit.