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.
MergeTreeData & checkStructureAndGetMergeTreeData(const StoragePtr & source_table, const StorageMetadataPtr & src_snapshot, const StorageMetadataPtr & my_snapshot) const;
    MergeTreeData & checkStructureAndGetMergeTreeData(IStorage & source_table, const StorageMetadataPtr & src_snapshot, const StorageMetadataPtr & my_snapshot) const;
    struct HardlinkedFiles
    {
        
        std::string source_table_shared_id;
        
        std::string source_part_name;
        
        NameSet hardlinks_from_source_part;
    };
    MergeTreeData::MutableDataPartPtr cloneAndLoadDataPartOnSameDisk(
        const MergeTreeData::DataPartPtr & src_part, const String & tmp_part_prefix,
        const MergeTreePartInfo & dst_part_info, const StorageMetadataPtr & metadata_snapshot,
        const MergeTreeTransactionPtr & txn, HardlinkedFiles * hardlinked_files,
        bool copy_instead_of_hardlink);
    virtual std::vector<MergeTreeMutationStatus> getMutationsStatus() const = 0;
    
    
    virtual bool canUseAdaptiveGranularity() const
    {
        const auto settings = getSettings();
        return settings->index_granularity_bytes != 0 &&
            (settings->enable_mixed_granularity_parts || !has_non_adaptive_index_granularity_parts);
    }
    
    
    
    MergeTreeSettingsPtr getSettings() const