**Describe the bug**
For DATABASE ENGINE Atomic (used by Default for all databases from 20.10) 
when try to `DROP TALBE replicatedmergetree table ON CLUSTER ... SYNC`, query failed after `distributed_ddl_task_timeout` seconds
`decrease `database_atomic_delay_before_drop_table_sec=1` and setup `database_atomic_wait_for_drop_and_detach_synchronously=1` for default user profile didn't help

**How to reproduce**
just look to https://gist.github.com/Slach/a7f2946a108883f6b1d5585b1b5b6b0d
```
bash -x ./reproduce.sh
```

* Which ClickHouse server version to use
Latest official docker build

* Non-default settings, if any
```
<yandex>
    <database_atomic_delay_before_drop_table_sec>1</database_atomic_delay_before_drop_table_sec>
    <profile>
        <default>
            <database_atomic_wait_for_drop_and_detach_synchronously>1</database_atomic_wait_for_drop_and_detach_synchronously>
            <distributed_ddl_task_timeout>20</distributed_ddl_task_timeout>
        </default>
    </profile>
</yandex>

```

**Expected behavior**
Successfull DROP TABLE on cluster

**Error message and/or stacktrace**
Code: 159. DB::Exception: Received from localhost:9000. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000000001 is executing longer than distributed_ddl_task_timeout (=20) seconds. There are 2 unfinished hosts (0 of them are currently active), they are going to execute the query in background.

**Additional context**
table physically deleted, but Atomic engine doesn't return "finished" flag to Zookeeper `distributed_ddl` queue

```
docker-compose exec clickhouse-0-0-0 clickhouse-client -q "SELECT * FROM system.zookeeper WHERE path='/clickhouse/task_queue/ddl/query-0000000001/finished' FORMAT
Vertical"
```

returns empty result


String cluster_name;
    ClusterPtr cluster;
    Cluster::Address address_in_cluster;
    size_t host_shard_num;
    size_t host_replica_num;
    bool is_circular_replicated = false;
    
    ExecutionStatus execution_status;
    bool was_executed = false;
    
};
namespace
{
/** Caveats: usage of locks in ZooKeeper is incorrect in 99% of cases,
  *  and highlights your poor understanding of distributed systems.
  *
  * It's only correct if all the operations that are performed under lock
  *  are atomically checking that the lock still holds
  *  or if we ensure that these operations will be undone if lock is lost
  *  (due to ZooKeeper session loss) that's very difficult to achieve.
  *
  * It's Ok if every operation that we perform under lock is actually operation in ZooKeeper.
  *
  * In 1% of cases when you can correctly use Lock, the logic is complex enough, so you don't need this class.
  *
  * TLDR: Don't use this code.
  * We only have a few cases of it's usage and it will be removed.
  */
class ZooKeeperLock