@antonio2368 , after https://github.com/ClickHouse/ClickHouse/pull/36258 and https://github.com/ClickHouse/ClickHouse/issues/35465

I tried to test your --force-recovery implementation and failed, totally

when we try to scale down zookeeper cluster from 3 nodes to 1 nodes we need only one keeper node 
`clickhouse-keeper --force-recovery` can't start properly, cause still wait 2 other nodes, even when have only one node in peer list in XML config

```
 <Information> KeeperDispatcher: Server is recovering, will not apply configuration until recovery is finished
```

> Again, keep in mind that such configuration changes are already possible with the Keeper if there is a quorum by just changing the XML.

I can't to do it inside all other keeper nodes, inside Kubernetes

kubernetes operates pods and containers in declarative manner, I see only one opportunity to use
```yaml
          lifecycle:
            preStop: |
              shell script which will rewrite XML config
```
but it doesn't allow us to change XML configs on other pods during scale down

Moreover, we don't have support `reconfigure add` and `reconfigure remove` zookeeper commands and can't remove Pod from Quorum peer list dynamic

So, it makes --force-recovery useless in Kubernetes ;(

@alesapin maybe you could suggest how to run clickhouse-keeper in Kubernetes with scale down operation support?

{
    nuraft::raft_params params;
    params.heart_beat_interval_
        = getValueOrMaxInt32AndLogWarning(coordination_settings->heart_beat_interval_ms.totalMilliseconds(), "heart_beat_interval_ms", log);
    params.election_timeout_lower_bound_ = getValueOrMaxInt32AndLogWarning(
        coordination_settings->election_timeout_lower_bound_ms.totalMilliseconds(), "election_timeout_lower_bound_ms", log);
    params.election_timeout_upper_bound_ = getValueOrMaxInt32AndLogWarning(
        coordination_settings->election_timeout_upper_bound_ms.totalMilliseconds(), "election_timeout_upper_bound_ms", log);
    params.reserved_log_items_ = getValueOrMaxInt32AndLogWarning(coordination_settings->reserved_log_items, "reserved_log_items", log);
    params.snapshot_distance_ = getValueOrMaxInt32AndLogWarning(coordination_settings->snapshot_distance, "snapshot_distance", log);
    if (params.snapshot_distance_ < 10000)
        LOG_WARNING(log, "Very small snapshot_distance {} specified in coordination settings. "
                    "It doesn't make sense to specify such small value, because it can lead to degraded performance and another issues.", params.snapshot_distance_);
    params.stale_log_gap_ = getValueOrMaxInt32AndLogWarning(coordination_settings->stale_log_gap, "stale_log_gap", log);
    params.fresh_log_gap_ = getValueOrMaxInt32AndLogWarning(coordination_settings->fresh_log_gap, "fresh_log_gap", log);
    params.client_req_timeout_
        = getValueOrMaxInt32AndLogWarning(coordination_settings->operation_timeout_ms.totalMilliseconds(), "operation_timeout_ms", log);
    params.auto_forwarding_ = coordination_settings->auto_forwarding;
    params.auto_forwarding_req_timeout_
        = std::max<uint64_t>(coordination_settings->operation_timeout_ms.totalMilliseconds() * 2, std::numeric_limits<int32_t>::max());
    params.auto_forwarding_req_timeout_
        = getValueOrMaxInt32AndLogWarning(coordination_settings->operation_timeout_ms.totalMilliseconds() * 2, "operation_timeout_ms", log);