Original Ticket:

In build(Un)versionedRequestsFor(All)TargetedShards that are used in explains count and distinct
same thing as in cluster find and aggregate commands - look how it can reuse the code.
in cluster_commands_helpers.cpp

Summary:

Given a BSON command object with readConcern level snapshot, replace its snapshot readConcern with a new snapshot readConcern with atClusterTime. Since the cmd obj already has a readConcern field, the object will be iterated over, copying all of its fields that are not readConcern, then the new readConcern will be appended at the end.

Details:

BSONObj appendAtClusterTime(BSONObj cmdObj, LogicalTime atClusterTime) {
    // Append all original fields except the readConcern field to the new command.
    BSONObjBuilder bob;
    for (auto elem : cmdObj) {
        const auto name = elem.fieldNameStringData();
        if (name != "readConcern") {
            bob.append(elem);
        }
    }

    // Add the new snapshot readConcern with atClusterTime.
    BSONObjBuilder readConcernBob(bob.subobjStart("readConcern"));
    readConcernBob.append("level", "snapshot");
    readConcernBob.append("atClusterTime", atClusterTime.asTimestamp());
    readConcernBob.doneFast();

    return bob.obj();
}

Open Questions:

• Can appendAtClusterTime receive a cmdObj with no readConcern?
  • It should have readConcern: "snapshot" to trigger the GPITR code, so I don't think so.

Unit tests:

• Given a BSONObj with each readConcern level, verify appendAtClusterTime overwrites the existing level

POC: https://mongodbcr.appspot.com/178800002/