If a migration's protocol is "shard merge" then the donor donates all data to the recipient, not just one tenant's data. Thus there's no tenantId. Omit it from the replies of the diagnostic commands serverStatus and currentOp for migrations with protocol "shard merge".

(Until the Shard Merge project is complete, "shard merge" migrations still use tenantId. We're gradually implementing shard merge to the point where it doesn't need a tenantId. But we can remove tenantId from serverStatus and currentOp now.)

The code is in reportForCurrentOp() in tenant_migration_donor/recipient_service.h/cpp, and appendInfoForServerStatus() in tenant_migration_access_blocker_registry.cpp and tenant_migration_donor/recipient_access_blocker.cpp.

Search for "tenantMigrationAccessBlocker" in the jstests/replsets directory and you'll see that most of the work for this ticket may be updating tests. We use the same tests for the old and new migration protocols, so they must expect different currentOp and serverStatus formats depending on the protocol. Let's make a nicely-factored utility for the JS tests to abstract that difference away.