REP-6465 Fix handling of dotted shard keys

[FGasper]

This fixes Migration Verifier’s logic to assemble a document key given a full document and field names when any of those fields has a dot.

When the server routes a document whose collection is sharded on, e.g., {foo.bar: 1}, it does so based on the value of /foo/bar (i.e., the bar field of the top-level embedded document named foo) in the document. Migration Verifier instead assembled its document key from the value at /foo.bar (i.e., a top-level field named foo.bar).

This fixes the bug. Notably, it also avoids the problem, documented in SERVER-109340, where the server’s change stream’s documentKey inaccurately reports the values used to route the document.

[mmcclimon]

I mean, this seems fine? I'm deeply suspicious of the aggregation pipeline because I do not feel at all qualified to review that, so you might also get a review from someone that does. The tests seem to pass though, but you might want some more cases for weird things (notably, arrays where you might get depth-traversal errors).

[mmcclimon]

You probably also want to handle bsoncore.ErrInvalidDepthTraversalError here, which is the kind of error you get if you have a shard key like a.b and the a field in the target document is an array.

[mmcclimon]

Typically this is called in a defer right after we open successfully.

[FGasper]

I didn’t have it that way because it was in a loop, but I’ve rewritten it now to be a subtest, which has its own callback and so can use defer.