This means we'll have to call listCollections twice on the primary shard if we want to avoid shardCollection being able to fail after creating the collection on the shard. We should avoid this because the user may change the options to shardCollection to try to fix their issue, and the new options may be incompatible with the options the collection was just created with. For example, if the first (failed) shardCollection attempt specified one shard key and passed the 'unique' option, and the second attempt specifies a different shard key, the second attempt will fail because a unique index was created on the shard with the first key.

Depends on SERVER-29858, since we don't want to add new uses of DBClient in sharding, but ShardRemote does not have a way to iterate a cursor on shards.