We should make below existing tenant migration passthrough suites to work with shard merge protocol.
1. tenant_migration_causally_consistent_jscore_passthrough.yml
2. tenant_migration_multi_stmt_txn_jscore_passthrough.yml
3. tenant_migration_jscore_passthrough.yml
4. tenant_migration_kill_primary_jscore_passthrough.yml
5. tenant_migration_terminate_primary_jscore_passthrough.yml
6. tenant_migration_stepdown_jscore_passthrough.yml

In milestone1, shard merge is not robust to restarts/failover (irrespective of donor/recipient). So, as part of this ticket, we should make passthrough suites 1 through 3 to work with shard merge protocol as well. Additionally, passthrough suites 4 through 6 should be disabled on the all feature flag build variant. But, once the milestone 3 (Robustness of shard merge) is complete, we should re-revaluate if we need to re-enable the passthrough suites (4 through 6) for shard merge protocol.

EDIT:

It was decided in this patch to only support the vanilla passthrough (#3) test as a first batch of change and address (#1, #2) in SERVER-67860 and backlisting (4 thru 6) in SERVER-68605

EDIT2:

We are also going to temporary by pass the validate_collection logic which is currently failing due to `fast count (14) does not match number of records (6) for collection`
Fast counts are no longer transactional/atomic with the inserts/deletes they are associated with, so we can have mismatch between fast count and on-disk record count for imported donor collections during a shard merge.
We will re-introduce the validate collection logic in SERVER-61476