In sharded clusters, the dropIndexes operation is not supported (yet) by a DDL coordinator. Although it currently acquires the DDL lock, there is no guarantee that other concurrent DDL operations won't begin while the participant shards are still processing the dropIndexes operation invoked here.

Example:

1. The database primary shard invokes dropIndexes on the participant shards
2. The primary node of the database primary shard steps down (releasing the scoped DDL lock)
3. A DDL operation starts on the new primary node of the database primary shard
4. A participant shard processes the dropIndexes command received by step (1)

Once the dropIndexes operation will be backed by a DDL coordinator, it will be guaranteed that the dropIndexes operation will eventually succeed before a new DDL like movePrimary may start.

Given that, it will not be needed anymore to perform assertNoMovePrimaryInProgress checks:

$ git grep MovePrimaryInProgress src/mongo/db/catalog/drop_indexes.cpp
src/mongo/db/catalog/drop_indexes.cpp:void assertNoMovePrimaryInProgress(OperationContext* opCtx, const NamespaceString& nss) {
src/mongo/db/catalog/drop_indexes.cpp:        bool isMovePrimaryInProgress =
src/mongo/db/catalog/drop_indexes.cpp:                ->isMovePrimaryInProgress();
src/mongo/db/catalog/drop_indexes.cpp:            if (isMovePrimaryInProgress) {
src/mongo/db/catalog/drop_indexes.cpp:                LOGV2(4976500, "assertNoMovePrimaryInProgress", logAttrs(nss));
src/mongo/db/catalog/drop_indexes.cpp:                uasserted(ErrorCodes::MovePrimaryInProgress,
src/mongo/db/catalog/drop_indexes.cpp:        if (ex.toStatus() != ErrorCodes::MovePrimaryInProgress) {
src/mongo/db/catalog/drop_indexes.cpp:            assertNoMovePrimaryInProgress(opCtx, collPtr->ns());

NB: this ticket must be executed after the dropIndexes DDL coordinator has made it into an LTS version because the check is still needed when the operation is running on clusters in older FCV.