ShardRegistry::getShard(NoReload) accepts a ShardId and returns the associated Shard object. Confusingly, the _lookup map it uses actually contains HostAndPort and ConnectionStrings as keys in addition to ShardIds, so getShard(NoReload) can implicitly work with either of those types, since they're all essentially strings.

The ShardingEgressMetadataHook and the newly added CommittedOpTimeMetadataHook both use this behavior because the replySource given to each can be either a HostAndPort or a replica set ConnectionString, depending on which type of network connection was used (ASIO vs. DBClientReplicaSet).

To make debugging simpler, this value should be logged (and possibly parsed). Alternatively, we could change the two hooks that rely on this behavior to parse the replySource first and call an appropriate ShardRegistry method instead.