This test (`rename_collection_staytemp.js`) creates collections directly using applyOps commands. Using a replica set endpoint, those collections are not tracked by the sharding catalog and therefore not discoverable by listCollections commands that go through the router.

To give a little bit more of context, DDLs which run through the applyOps command are not sharding-aware and only operate against the local catalog. Therefore, in the case where we start requiring all collections to be tracked, applyOps should be banned from executing even directly against the shard, because it will leave the catalog corrupted. That's what is happening in `rename_collection_staytemp.js` test with the replica set endpoint.

In order to tackle this ticket we will need to decide how we want to solve it first:

• Make mongorestore not use applyOps and instead invoke DDL/CRUD commands.
• Implement an applyOps command processor in the router role of the core server.

Summarizing, this ticket tracks the work to unban `rename_collection_staytemp.js` to be run on replica set endpoint suites.