The multitenant migrations process begins when Cloud calls donorStartMigration on the donor primary with a tenantId. The donor calls recipientSyncData on the recipient primary with the tenantId. On both sides, we have ugly code for preventing concurrent migrations with the same tenantId. In SERVER-60752 we added an API to make such conflict-detection cleaner.

This ticket will need at least 3 commits:

1. Using the new API introduced in SERVER-60752, clean up the conflict detection code in the recipientSyncData command. The change we made in the donorStartMigration command in SERVER-60752 is a good example to start from.
2. The donorStartMigration command already uses the new API to ban multiple migrations with the same tenantId. (Well, once SERVER-60752 is committed.) We're adding a new concept of the migration "protocol", which can be "multitenant migrations" (old protocol, the default) or "shard merge" (the new one). Add a new rule: if any active migration has protocol "shard merge" it must be the only migration - other migrations are banned regardless of their protocol or tenantId. So if there's any existing migration then a new "shard merge" is banned. If there's an existing "shard merge", any new migration is banned.
3. Same change as #2, but for recipientSyncData.