The legacy range deleter was closely tighten to the metadata manager so this unit test was aimed to check that waitForClean was behaving well in case the metadata were cleared after scheduling a range deletion.

With the new range deleter service that is independent from the metadata manager, the waitForClean behavior can't possibly be influenced by clearing or setting new metadata. Hence this unit test can go away.

It also makes sense to get rid of it because the test gets stuck if the range deletion starts right between clearing and setting again the filtering metadata. The deadlock is not a bug, but a unit test lack since the onShardVersionMismatch invocation/response are not mocked. And mocking it would not add any value since the unit test is not that meaningful anymore.