As described in this section of the design document, _configsvrRefineCollectionShardKey should validate the following things about the shard key given to refineCollectionShardKey:

1. The key must extend the current shard key of the given namespace.
2. There must exist a "useful" index for the new key, i.e. non-sparse, non-partial with the same uniqueness as the key and contains the new key as a prefix.
   1. This should be able to re-use the corresponding checks from _configsvrShardCollection. Note that if there is no such index and the collection is empty, the index should not be created.
3. All shards must have no null entries in the shard key index
   1. This should also re-use the above checks from sharding a collection.

Additionally, if the proposed shard key is already the shard key of the given namespace, then the command should return success without taking any action after setting the client's last op to the system last opTime (example from shardCollection).

All of these checks should happen after taking distributed locks on the namespace's database and collection.

The following test cases should be added to jstests/sharding/refine_collection_shard_key_basic.js:

• A refine will fail if the given key does not extend the current shard key.
• A refine will fail if there is not a useful index.
  • It should be verified the refine fails even if every kind of non-useful index is present, i.e. will fail if there is only a sparse, partial, multikey, etc. index on the shard key.
• A refine will fail if the original shard key was unique and the only useful index has the new shard key as a prefix.
  • e.g. the old key is a:1 and the new key is a:1, b:1 and there is only an index on a:1, b:1, c:1
• A refine will not fail if the original shard key was not unique and the only useful index has the new shard key as a prefix.
• A refine will fail if there is a useful index, but any shard has a null entry in that index.
• A refine will succeed if the proposed key is already the collection's shard key.