**Describe the bug:**

Create a table with very long column names or type names (type names can be long for legitimate reason, e.g. Enum).
Make table structure to be less than 1 MB but larger than 100 KB.

Create two replicas, turn one replica off. Execute at least 10 ALTER queries to slightly modify columns in the table.
Turn second replica on.

It will fail with:
```
<Debug> sandbox.taskdiskusage (ReplicatedMergeTreeQueue): Pulling 42 entries to queue: log-0001412404 - log-0001412445
...
<Error> void Coordination::ZooKeeper::receiveThread(): Code: 33, e.displayText() = DB::Exception: Cannot read all data. Bytes read: 0...
```
(there is no subsequent message `Pulled 42 entries to queue`)

Because it tries to make a transaction to move several `log` entries to `queue` (the code is in `ReplicatedMergeTreeQueue::pullLogsToQueue` function) and this transaction is larger than 1 MB.

After this message all other ZooKeeper queries will fail with `Session expired` error.
After the session to ZooKeeper is reinitialized, everything will repeat.

**Workaround:**

1 MB is the default limit for packet size in ZooKeeper. You should increase it with the parameter `-Djute.maxbuffer` in ZooKeeper.

**Notes:**

There was no such issue with ALTER columns queries before version 20.3. In version 20.3 ALTER of columns goes through the replication log, the change was added in #8701. It means that the issue may manifestate itself after upgrade to the versions 20.3+. But the root cause of the bug itself is present in every version, you can get similar effect with ALTER UPDATE or DELETE if the expression is very long (e.g. long list of constants).
ActiveDataPartSet current_parts;
    /** The queue of what you need to do on this line to catch up. It is taken from ZooKeeper (/replicas/me/queue/).
      * In ZK records in chronological order. Here they are executed in parallel and reorder after entry execution.
      * Order of execution is not "queue" at all. Look at selectEntryToProcess.
      */
    Queue queue;
    InsertsByTime inserts_by_time;
    time_t min_unprocessed_insert_time = 0;
    time_t max_processed_insert_time = 0;
    time_t last_queue_update = 0;
    
    
    using FuturePartsSet = std::map<String, LogEntryPtr>;
    FuturePartsSet future_parts;
    
    Int64 log_pointer = 0;
    
    bool currently_executing_drop_or_replace_range = false;
    /** What will be the set of active parts after executing all log entries up to log_pointer.
      * Used to determine which merges can be assigned (see ReplicatedMergeTreeMergePredicate)
      */
    ActiveDataPartSet virtual_parts;
    
    
    
    
    struct MutationStatus
    {
        MutationStatus(const ReplicatedMergeTreeMutationEntryPtr & entry_, MergeTreeDataFormatVersion format_version_)