For some reasons when we delete a MergeTree Part in atomic way something may go wrong - and leave the `delete_tmp_*` folder or it's part on disk. This may lead to a disk space consumption over time.

It's suggested to delete this folders at least at server start-up. Current solution with `clearOldTemporaryDirectories()` doesn't work because this method is called periodically from a thread without any locks or advisory on folders - it may cause the race conditions.
{
    auto zookeeper = getZooKeeper();
    Strings expected_parts_vec = zookeeper->getChildren(fs::path(replica_path) / "parts");
    
    NameSet expected_parts(expected_parts_vec.begin(), expected_parts_vec.end());
    
    auto parts = getDataParts({MergeTreeDataPartState::Active, MergeTreeDataPartState::Outdated});
    /** Local parts that are not in ZK.
      * In very rare cases they may cover missing parts
      * and someone may think that pushing them to zookeeper is good idea.
      * But actually we can't precisely determine that ALL missing parts
      * covered by this unexpected part. So missing parts will be downloaded.
      */
    DataParts unexpected_parts;
    
    for (const auto & part : parts)
        if (!expected_parts.contains(part->name))
            unexpected_parts.insert(part); 
    
    Strings parts_to_fetch;
    for (const String & missing_name : expected_parts)
        if (!getActiveContainingPart(missing_name))
            parts_to_fetch.push_back(missing_name);
    /** To check the adequacy, for the parts that are in the FS, but not in ZK, we will only consider not the most recent parts.
      * Because unexpected new parts usually arise only because they did not have time to enroll in ZK with a rough restart of the server.
      * It also occurs from deduplicated parts that did not have time to retire.
      */
    size_t unexpected_parts_nonnew = 0;