Shard merge does non-timestamped catalog writes when importing collections (i,e, collections created during physical cloning phase). But, does timestamped catalog writes when dropping those collections. This mixed timestamp mode usage can trigger invariant failure in HistoricalCatalogIdTracker which was introduced to support point-in-time catalog lookups PM-2218.

Noting the problematic sequence here.

1. Fixture starts migrationId1.
2. Recipient imports the donor collection  say <tenanId1>_db.coll untimestamped.
   a) <catalogRecordID<X>,  boost::none TS> entry gets inserted into HistoricalCatalogIdTracker for this nss.
3. migrationid1 get committed.
4. Fixture drops the collection <tenanId1>_db.coll but it’s timestamped writes with dropTS as TS(100).
   a) <boost::none,  TS(100)> entry gets inserted into HistoricalCatalogIdTracker for this nss.
5. Fixture starts another migrationId2.
6. Recipient imports the donor collection  say <tenanId1>_db.coll untimestamped.
   a) This will skip inserting entry into HistoricalCatalogIdTracker as HistoricalCatalogId list is non-empty for this nss.
7. When the oldest ts  is no longer < TS(100), TimestampMonitor deletes the expired 2-a) and 4-a) entries from HistoricalCatalogIdTracker.
8. migrationid2 get committed.
9. Fixture drops the collection <tenanId1>_db.coll but it’s timestamped writes.
   a) This throws the invariant failure because HistoricalCatalogId list is empty for this nss.