**Describe the bug**
The ClickHouse client freezes when executing `ALTER TABLE` with `ADD COLUMN` and `MODIFY ORDER` on a table built using Replicated Versioned Collapsing Merge Tree engine.

**How to reproduce**
* ClickHouse client version 20.10.1.1.
Connecting to localhost:9000 as user default.
Connected to ClickHouse server version 20.10.1 revision 54440.

* `CREATE TABLE` statements
```
SHOW CREATE TABLE table0

┌─statement──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE default.table0
(
    `d` Date,
    `a` String,
    `b` UInt8,
    `x` String,
    `y` Int8,
    `version` UInt64,
    `sign` Int8 DEFAULT 1
)
ENGINE = ReplicatedVersionedCollapsingMergeTree('/clickhouse/tables/{shard}/table0', '{replica}', sign, version)
PARTITION BY y
ORDER BY d
SETTINGS index_granularity = 8192 │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

1 rows in set. Elapsed: 0.004 sec.
```

* Queries to run that lead to unexpected result
```
ALTER TABLE table0 ADD COLUMN order UInt32, MODIFY ORDER BY (d, order)
```
if (storage_settings_ptr->replicated_max_parallel_fetches_for_table
        && current_table_fetches >= storage_settings_ptr->replicated_max_parallel_fetches_for_table)
    {
        throw Exception("Too many fetches from replicas for table, maximum: " + storage_settings_ptr->replicated_max_parallel_fetches_for_table.toString(),
            ErrorCodes::TOO_MANY_FETCHES);
    }
    ++current_table_fetches;
    SCOPE_EXIT({--current_table_fetches;});
    try
    {
        if (replica.empty())
        {
            /** If a part is to be written with a quorum and the quorum is not reached yet,
              *  then (due to the fact that a part is impossible to download right now),
              *  the quorum entry should be considered unsuccessful.
              * TODO Complex code, extract separately.
              */
            if (entry.quorum)
            {
                if (entry.type != LogEntry::GET_PART)
                    throw Exception("Logical error: log entry with quorum but type is not GET_PART", ErrorCodes::LOGICAL_ERROR);
                LOG_DEBUG(log, "No active replica has part {} which needs to be written with quorum. Will try to mark that quorum as failed.", entry.new_part_name);
                /** Atomically:
                  * - if replicas do not become active;
                  * - if there is a `quorum` node with this part;
                  * - delete `quorum` node;
                  * - add a part to the list `quorum/failed_parts`;
                  * - if the part is not already removed from the list for deduplication `blocks/block_num`, then delete it;
                  *
                  * If something changes, then we will nothing - we'll get here again next time.