createIndexes (and dropIndexes) may not create index (or leave index around) if migration happens concurrently

Bug #1: It's possible to get ok:1 from createIndexes, but not have the index propagated to all shards if a migration happens in between the recipient and donor shards processing the createIndexes.

In this case, the raw response for the createIndex from each shard will contain either CannotImplicitlyCreateCollection or ok:1, and the overall createIndexes command will return ok:1.

Today, to remedy this, createIndexes can be re-run against against the mongos. This second createIndexes will return ok:1, since createIndexes is idempotent.

Bug #2: It's possible to get ok:1 from dropIndexes, but have the index get created afterwards on some shard if a migration happens in between the recipient and donor shards processing the dropIndexes.

In this case, the raw responses for the dropIndex from each shard will contain either NamespaceNotFound or ok:1, and the overall dropIndexes command response will be ok:1.

Today, to remedy this, dropIndexes can be re-run against the mongos. This second dropIndexes will return ok:0, since dropIndexes is not idempotent, but the index will get dropped from any shards that had the index.