[RFC]: 支持scheduler故障恢复

### 背景与目标描述. xx客户大集群场景，scheduler和worker分布在不同的机器上，当前对于worker故障做了高可用处理，当某台节点或某张卡（非rank0）发生故障，会启用备用节点替换故障节点，不影响整个集群继续工作。  但是scheduler节点发生故障，当前的处理方式是job重新调度，重调度涉及容器重新拉起，需要加载ckpt、执行编译、建链等整体流程，耗时较长，极其影响训练效率。 因此，当前客户的需求是，期望scheduler节点故障后，支持故障恢复，不影响worker节点正常运行，不影响后续worker的故障恢复。 ### 方案设计 #### 当前用户背景信息： 1、用户使用K8S集群组网，可以监控整网状态，无需使用ms的心跳功能。当前用户已经关闭了心跳功能，即当worker正常工作后，不再与scheduler进行交互。 2、scheduler节点在集群拉起后的作用在于下一次的worker故障恢复，使用host组网交换节点的建链信息。 **基于现状分析以下方案，当前综合分析，推荐使用方案一：** #### 方案一：打开心跳（配置较长心跳间隔），worker检测到scheduler故障后，定时重连，当scheduler重新拉起后，重连成功，worker停止重连并重新跟scheduler注册。  详细方案：左图为当前已有流程，右图为适配sch故障重启流程。  使用步骤： 1、打开心跳开关，默认为打开心跳。设置MS_DISABLE_HEARTBEAT=1表示关闭。 2、设置心跳检测间隔，MS_RETRY_INTERVAL_LOWER和MS_RETRY_INTERVAL_UPPER为一个合适的时间。要小于MS_TOPO_TIMEOUT，不影响网络。 3、设置心跳超时退出时间，MS_HEARTBEAT_RETRY_TIMEOUT为一个能够容忍sch故障重启的时间。 4、当检测到sch退出后，会进行重新建链操作，同时如果建链成功，重新发送一条重注册消息给sch，当sch接收到所有卡的建链成功消息，及完成故障恢复。 场景限制：如果sch故障重启为完成期间，worker发生故障，无法恢复。 优点：启动流程无需变化，复用当前心跳流程，代码修改量较小。且用户只需要修改环境变量即可。 缺点：worker重连，会增加网络通信。当心跳设置时间较长时，网络拥塞影响可控。 工作量：0.5人月 #### 方案二：让用户修改启动策略，使用无scheduler启动，使用tcpstore替代scheduler，当前rank0节点故障是不恢复的，因此将tcpstore布置在rank0上即可实现该功能。  优点：当前tcpstore已有功能即可支持，后端基本无开发工作量 缺点：用户流程会发生变化。 1、需要用户适配脚本拉起msrun，但当前msrun需要传入sch地址，因此虽然不支持sch，用户启动脚本还是需要传入sch。 2、当前用户将sch跟worker进行隔离，不在一个容器中，当前场景实际是不在一个机器上，是为了保障各个节点之间cpu占用平稳。如果无sch启动，实际tcpstore会存在某张节点上，这台简单需要跟所有卡进行建链，可能会影响worker节点的均衡性。 3、改动sch启动方式，故障快恢流程会需要跟随适配。当前故障快恢依赖sch功能。 4、sch在大集群启动场景可以快速检测到有没有卡故障无法拉起等问题，不启动sch会带来拉起问题定位困难。 工作量：后端只需要支撑业务适配流程即可，用户和快恢需要修改适配 #### 方案三：scheduler故障后，重新拉起后，hang住不在工作，当发生worker故障重新建链时，将host通信域也重新建链一次。 …