Supports switch selection for cluster automatic recovery when more than half of the nodes lose storage data

[ShawnQiang1]

Description

When a disaster recovery scenario occurs, and it makes it impossible to elect the master node, what user need to do

1. When the cluster loses more than half of its master-eligible nodes, you need to use the elasticsearch-node unsafe-bootstrap command to perform unsafe boot recovery
2. All remaining nodes must be stopped
3. Select one of the remaining master-eligible nodes as the new elected master node. The selection criteria is the node with the largest term. If the terms are the same, the node with the largest version is selected.
4. Run the elasticsearch-node unsafe-bootstrap command on the selected node
5. Run the elasticsearch-node detach-cluster tool on each other node in the cluster.
   This tool resets the node's cluster UUID, allowing it to join a new cluster with a different UUID.

However, this series of operations cannot be completed automatically, If it is clear in advance that data loss is acceptable, can a switch option be set to automatically complete the above operations?

[elasticsearchmachine]

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

[DaveCTurner]

Since this last-ditch process requires modifying each node's data path while the node is shut down, there is not a lot we can do to automate it within Elasticsearch. Moreover, this should be an extraordinarily rare situation: it requires a disaster in which multiple independent nodes all irretrievably vanish and at the same time the loss of all recent snapshots. Theoretically possible of course, but I'm pretty sure I've never seen it happen in practice. Definitely doesn't seem worth optimizing such a rarely-used process.