One of our users just killed mutations produced by `ALTER MODIFY` queries on 21 servers. After that new alters on three servers stuck with:
```
Cannot execute alter metadata with version: 8 because another alter 7 must be executed before
```

However, there is no corresponding alter №7 in the replication queue and no undone mutations:
```
select * from system.mutations where is_done = 0
```

However, in the ZooKeeper, we have the correct state of metadata_version:
```
Row 13:
───────
name:           metadata_version
value:          7
czxid:          23078663291
mzxid:          29401964979
ctime:          2020-09-02 17:52:08
mtime:          2020-11-13 00:43:18
version:        7
cversion:       0
aversion:       0
ephemeralOwner: 0
dataLength:     1
numChildren:    0
pzxid:          23078663291
```
`SYSTEM RESTART REPLICA dbname.table_name` solves the issue, but it seems like` KILL MUTATION` in some cases can lead to unfinished alter.
if (merger_mutator.merges_blocker.isCancelled())
        {
            const char * format_str = "Not executing log entry {} of type {} for part {} because merges and mutations are cancelled now.";
            LOG_DEBUG(log, format_str, entry.znode_name, entry.typeToString(), entry.new_part_name);
            out_postpone_reason = fmt::format(format_str, entry.znode_name, entry.typeToString(), entry.new_part_name);
            return false;
        }
        if (merge_strategy_picker.shouldMergeOnSingleReplica(entry))
        {
            auto replica_to_execute_merge = merge_strategy_picker.pickReplicaToExecuteMerge(entry);
            if (replica_to_execute_merge && !merge_strategy_picker.isMergeFinishedByReplica(replica_to_execute_merge.value(), entry))
            {
                String reason = "Not executing merge for the part " + entry.new_part_name
                    +  ", waiting for " + replica_to_execute_merge.value() + " to execute merge.";
                out_postpone_reason = reason;
                return false;
            }
        }
        UInt64 max_source_parts_size = entry.type == LogEntry::MERGE_PARTS ? merger_mutator.getMaxSourcePartsSizeForMerge()
                                                                           : merger_mutator.getMaxSourcePartSizeForMutation();
        /** If there are enough free threads in background pool to do large merges (maximal size of merge is allowed),
          * then ignore value returned by getMaxSourcePartsSizeForMerge() and execute merge of any size,
          * because it may be ordered by OPTIMIZE or early with different settings.
          * Setting max_bytes_to_merge_at_max_space_in_pool still working for regular merges,
          * because the leader replica does not assign merges of greater size (except OPTIMIZE PARTITION and OPTIMIZE FINAL).
          */
        const auto data_settings = data.getSettings();
        bool ignore_max_size = false;
        if (entry.type == LogEntry::MERGE_PARTS)
        {