Discovery 初始集群发现

做的事：真实另起一个独立的ES实例，故意不配置discovery.type和cluster.initial_master_nodes，用默认的multi-node发现模式启动

代码真实的elasticsearch.yml配置(故意省略discovery.type和cluster.initial_master_nodes): cluster.name: disco-lab node.name: disco-node-1 discovery.seed_hosts: [] 真实启动这个独立进程，观察日志和HTTP端口状态

验证：进程真实正常启动了，但日志里明确写着还没加入一个"已引导"的集群，HTTP端口真实一直无法连接

真实日志里关键一行:
→ "using discovery type [multi-node] and seed hosts providers [settings]"
→ "this node has not joined a bootstrapped cluster yet;
   [cluster.initial_master_nodes] is set to []"

真实HTTP健康检查: HTTP_CODE=000（连接失败，不是400/500这种真实的业务错误）
真实进程状态: 用ps确认进程依然存活，没有崩溃退出

这组真实现象揭示了一个很关键的事实：这个节点真实没有崩溃，进程真实还在运行，但它真实永远卡在了"不知道该不该把自己选成master"这个状态——multi-node发现模式真实要求集群在第一次启动时，必须有人明确告诉它"这几个节点名字组成初始的候选master集合"（就是cluster.initial_master_nodes这个设置），没有这个信息，节点真实不敢擅自引导（bootstrap）一个全新的集群，因为真实害怕自己只是网络分区中暂时联系不上其他节点的其中一个，擅自引导可能会真实制造出两个各自为政的"脑裂"集群。正是这种真实的谨慎，导致HTTP层面在集群真正组建完成之前，真实根本没有启动监听，所以连接直接被拒绝。

真实加上cluster.initial_master_nodes指定这个节点自己的名字，重新启动，看能不能真实解开这个僵局

代码真实在配置里追加一行: cluster.initial_master_nodes: ["disco-node-1"] 真实清空数据目录后重新启动这个进程

验证：加上这一行配置之后，真实8秒内就成功组成了单节点集群，状态直接是green

真实重启后等待: up after 8s
GET /_cluster/health:
→ {"cluster_name":"disco-lab","status":"green","number_of_nodes":1,...}

分步演示：Discovery从永远卡住的僵局到配置正确后8秒内成功引导集群的完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。