**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 (MergeTreeDataPartChecksums::isBadChecksumsErrorCode(e.code()))
            {
                transaction.rollback();
                ProfileEvents::increment(ProfileEvents::DataAfterMergeDiffersFromReplica);
                LOG_ERROR(log, "{}. Data after merge is not byte-identical to data on another replicas. There could be several reasons: 1. Using newer version of compression library after server update. 2. Using another compression method. 3. Non-deterministic compression algorithm (highly unlikely). 4. Non-deterministic merge algorithm due to logical error in code. 5. Data corruption in memory due to bug in code. 6. Data corruption in memory due to hardware issue. 7. Manual modification of source data after server startup. 8. Manual modification of checksums stored in ZooKeeper. 9. Part format related settings like 'enable_mixed_granularity_parts' are different on different replicas. We will download merged part from replica to force byte-identical result.", getCurrentExceptionMessage(false));
                write_part_log(ExecutionStatus::fromCurrentException());
                tryRemovePartImmediately(std::move(part));
                
                
                return false;
            }
            throw;
        }
        /** Removing old parts from ZK and from the disk is delayed - see ReplicatedMergeTreeCleanupThread, clearOldParts.
          */
        /** With `ZSESSIONEXPIRED` or `ZOPERATIONTIMEOUT`, we can inadvertently roll back local changes to the parts.
          * This is not a problem, because in this case the merge will remain in the queue, and we will try again.
          */
        merge_selecting_task->schedule();
        ProfileEvents::increment(ProfileEvents::ReplicatedPartMerges);
        write_part_log({});
        return true;
    }
    catch (...)
    {
        write_part_log(ExecutionStatus::fromCurrentException());
        throw;
    }
}
bool StorageReplicatedMergeTree::tryExecutePartMutation(const StorageReplicatedMergeTree::LogEntry & entry)