【标题】(请简要描述下实现的内容)
优化cm_agent获取快照逻辑，不走dms，减少cm_agent获取状态异常的场景
【实现内容】:
优化cm_agent获取快照逻辑，不走dms，减少cm_agent获取状态异常的场景
【根因分析】:

1.单从当时的堆栈看，主机侧大多数在等MultiXactMemberControlLock的轻量级锁，包含多数业务线程加28个mes_task，而其中一个mes_task在持锁期间在走dss_close文件，在cs_uds_wait
2.备机侧51个线程在走SSMultiXactIdGetUpdateXid,触发主机回调获取MultiXactMemberControlLock的逻辑，其他线程多在问主机要快照、要xid状态等
3.等待一段时间后，cm查询自动恢复正常
4.而从日志自动打印的cm相关堆栈看，cm多是因为获取快照信息失败（有一个是在dss stat）
5.测试当时在执行select count(*), 这个走顺序扫描，且测试是在集群重启后查，表数据量大且大多数请求走磁盘，多会卡MultiXactMemberControlLock（传统版本也这样），表现是慢，但实际在运行

综上，cm查询状态异常可能是因为集群的瞬时卡顿，导致cm查询报错，从而判断异常

【实现方案】:
很早就想改掉这里，cm内部的查询语句都是调用的查系统函数，获取内存中的一些变量，所以我认为cm不需要关心可见性相关的东西，对于备机，就没必要走dms获取实时一致性的快照
直接返回null或者snapshotnow即可，这样至少不会导致cm自己报错从而干掉本来可能自动恢复的集群

【关联需求或issue】:
【测试类型：功能测试】【测试版本：5.1.0】【需求名称：资源池化】共享存储环境 tpcc主机读写，备机读 跑12小时+ kill业务进程 查询 备机unknown 一段时间后又恢复正常
https://e.gitee.com/opengaussorg/issues/table?issue=I7WQZB

【开发自验报告】:

1. 请附上自验结果(内容或者截图)

tpcc=# select count(*) from bmsql_config;
 count
-------
     4
(1 row)

tpcc=# select count(*) from  bmsql_customer;
  count
----------
 30000000
(1 row)

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

【其他说明】: