addShard (that is, the _configsvrAddShard command) sends setFeatureCompatibilityVersion to the to-be-added shard, to set the shard's FCV to match the cluster's.

If addShard runs concurrently with setFCV, the added shard can end up with the wrong FCV:

1) setFCV="3.6" called against a mongos, which forwards _configsvrSetFCV to the config server
2) configsvrSetFCV finishes sending setFCV to all existing shards
3) addShard is called
--> the FCV on the config server hasn't been set to 3.6 yet, so addShard will send setFCV=3.4 to the to-be-added shard

This ticket should make the addShard command take the featureCompatibilityVersionLock ResourceMutex.

Similarly, shardCollection (that is, the _configsvrShardCollection command) asks the primary shard for the collection's UUID, if the config server's FCV is 3.6 or is being upgraded to 3.6.

If shardCollection runs concurrently with setFCV, the collection's entry in config.collections can end up without a UUID:

1) shardCollection checks FCV, sees that it is 3.4, so does not ask primary shard for a UUID
2) setFCV="3.6" called, and config server sets FCV to (3.4, 3.6) aka upgrading
3) config server generates UUIDs for existing sharded collections
4) config server sends setFCV to shards
5) config server finishes upgrade, sets FCV to 3.6
6) shardCollection persists entry without a UUID in 'config.collections' for newly sharded collection