【标题】
解决按需回放部分问题

【实现内容】:
1.回放drop类型操作时的空指针异常；
2.按需回放阶段又发生故障，禁用再次恢复时采用按需回放；
3.按需回放阶段被恢复节点不允许加入集群，由打印warning并在后台等待修改为退出，避免normal reform时集群卡住

【根因分析】:
I7ITGE：由于资源池化中主备共享一份存储，现阶段不具备传统主备中pagerepair能力，因此在按需回放中删去了ClearRecoveryThreadHashTbl等函数。但是在drop操作的xlog回放函数中，仍调用了该函数，触发了空指针异常。
I7HRAU：按需回放阶段又发生故障，再次恢复时，需要选择原主节点进行恢复，也就是从上一次未完成恢复的redo点开始。由于上一次按需回放阶段又产生了大量的XLOG日志，且该阶段并未推进redo点，此时再采用按需回放，对内存消耗会非常高。因此禁用按需回放内又发生故障时，再采用按需回放。
I7FNVU：按需回放阶段对外提供服务后，DMS已经认为reform完成。此时如果用户手动重启被恢复节点，DMS会触发normal reform。由于按需回放特性约束按需回放阶段不允许原主加入集群，当前代码中会等待后台按需回放完成，实际升主的按需回放节点又在等待原主节点normal reform完成，进入不到startupxlog的里。

【实现方案】:
I7ITGE：按需回放增加ClearRecoveryThreadHashTbl等接口，但是不进行任何操作。
I7HRAU：按需回放阶段又发生故障，禁用再次恢复时采用按需回放，即使配置了按需回放开关，仍会选择极致RTO方式进行回放。
I7FNVU：按需回放未完成时，原主节点加入集群直接退出，避免normal reform时候各节点卡住。

【关联需求或issue】:
#I7ITGE:【资源池化】产生各种日志，进行按需回放数据库coredump
#I7HRAU:【资源池化】开启按需回放，触发failover，在备1failover的时候备机发生故障，触发备2failover，在备2按需回放阶段跑tpcc读写业务，数据出现key错误
#I7FNVU:【资源池化】开启按需回放，触发failover，在cm_ctl query查询到备升主成功后重启集群，一直卡在starting状态

【开发自验报告】:

1. 请附上自验结果(内容或者截图)
   issue中场景已自验
2. 是否可以添加fastcheck测试用例，如是，请补充fastcheck用例
3. 是否涉及资料修改，如是，在docs仓库补充资料
4. 是否考虑升级场景(系统表修改、日志持久化以及修改执行态数据格式)
5. 是否考虑在线扩容等扩展场景
6. 是否考虑异常场景/并发场景/前向兼容/性能场景
7. 是否对其他模块产生影响

【其他说明】: