A recent test regression revealed that under very specific conditions, the op entry generated during the commit of dropDatabase may bring the same ts value (tOpEntry) that gets later recorded within config.placementHistory once the operation gets persisted on the global catalog (tPlacementChange).

This is problematic, since it prevents change streams readers from being correctly resumed at ts; instead, each sharding DDL should always guarantee that tOpEntry < tPlacementChange.

The objective of this ticket is to amend the known regression in dropDatabase and audit the rest of the DDL operations.