@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?

{
    state_machine->shutdownStorage();
    state_manager->flushAndShutDownLogStore();
    shutdownRaftServer();
}
namespace
{
nuraft::ptr<nuraft::buffer> getZooKeeperLogEntry(int64_t session_id, int64_t time, const Coordination::ZooKeeperRequestPtr & request)