This code change alters the behavior of the dropDatabase command on sharded clusters, so that the commit of a user request is now matched by the generation of a single dropDatabase change event.

Prior to the change, multiple equivalent events were emitted (one by each data-bearing shard), referencing the same commit at different cluster times: such a behavior is considered a bug by the server team - and no change stream consumer should rely on it.

Description of Linked Ticket

As part of its commit phase, the Sharding DDL coordinator for  dropDatabase(dbName) requests (through a remote command) to each data-bearing shard the execution of a routine that removes from its local catalog and storage of any meta/data related to dbName; such a routine includes the generation of a c op entry, which the change streams machinery interprets as "a dropDatabase(dbName) user request has been completed" event.

We should ensure that the commit of a dropDatabase(dbName) request on a sharded cluster is matched by a single user-visible op entry generated by the primary shard of dbName (the ones generated by other data-bearing shards may be hidden through the {fromMigrate: true} op entry field).