In catalog shard mode, the key refresh will no longer use ShardLocal implementation underneath the keys loading machinery. The refresh() method will always first try to load keys explicitly remotely, and if the current cluster role is catalog shard (or config server), retry the keys loading locally.

CC tommaso.tocci@mongodb.com this is a good illustration (see PR) of how the refactoring works in general to support the catalog shard. Scroll to sharding_initialization.cpp change, the existing code is using the KeysCollectionClientSharded to access keys, and because underneath it's using Shard interface to read keys, it is using remote client when running on shards or mongs, and direct client on config.

After we refactor everything for catalog shard, the KeysCollectionClientSharded will be strictly remote, and KeysCollectionClientDirect strictly direct. At catalog shard the remote client will not work until the port is open, so the hedging with direct client will be triggered.

I am aware of the speed penalty, this will be fixed with different ticket using keys pre-loading at start, as described in design doc. This PR is 1/2 of the implementation outlined in design.