[DISCLAIMER] This is not a correctness bug, it only results in some garbage being left in the config.chunks collection.

SERVER-55115 changed the order to remove metadata for a specific collection from the config server: first the collection entry, then the chunks entries referring the dropped uuid. If a stepdown happens on the config server in between those steps, then it's possible to leave orphaned chunk entries around.

It has been observed this incriminated flow in a build failure:

• All participants returned success to the coordinator
• The coordinator called the ConfigsvrRenameCollectionMetadata command on the CSRS primary that was interrupted
  ... a step-down happened on the CSRS ...
  ... a step-up happened on the CSRS ...
• The coordinator retried, calling again the ConfigsvrRenameCollectionMetadata command on the CSRS that succeeded

The first command sent to the CSRS resulted in calling renameShardedMetadata that tried to remove collection and chunks entries, but only succeeded to remove the collection entry while the stepdown happened when trying to delete chunks.

As a consequence, the second command invocation on the CSRS followed the same flow but didn't try to remove chunk entries because the collection entry was not found.