【标题】(请简要描述下实现的内容)
修复alter role的core问题
【实现内容】:
修复alter role的core问题
【根因分析】:
出问题的SQL语句为 alter user u1 identified by aswd3456 replace dfg1637484kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkklll; 这条SQL首先是有语法错误，密码必须被单引号包裹，其次，由于openGauss的安全要求，在报错日志、审计日志等打印/记录SQL的场景，明文密码要做掩码，即 mask_Password_internal 函数的作用。在这条SQL中，需要做掩码的有两处，一个是 identified by 后面的新密码，一个是 replace 后面的旧密码。
当前密码掩码时，会把密码掩码成8位的星号（长度8受password_min_length guc参数控制），由于出错的场景是密码没有被单引号包裹，这种场景下，为了确保密码被正确的掩码了，计算要被掩码的密码长度时，一直获取到了字符串末尾，参考 mask_Password_internal 函数的 4510~4518 行代码。所以SQL语句经过一轮掩码后，变成了
alter user u1 identified by ********; 后面的replace xxx都被当成identified by后面的密码掩码了。
后续再读到 replace ，需要继续掩码dfg1637484kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkklll，由于原先的掩码字符串把这块都掩码过了，计算要掩码的字符串位置时，出现了负数，导致写数据写到了内存前面的header上，把内存前面的StandardChunkHeader给写坏了，最终在pfree的时候触发了断言core。
【实现方案】:
如果要掩码的字符串位置是负数，说明前面已经被掩码过了，不需要再次掩码了，跳过相关逻辑。确保内存操作不越界。
【关联需求或issue】:
https://e.gitee.com/opengaussorg/issues/table?issue=I69HWA
【开发自验报告】:

1. 请附上自验结果(内容或者截图)
   
2. 是否可以添加fastcheck测试用例，如是，请补充fastcheck用例
   是，已添加
3. 是否涉及资料修改，如是，在docs仓库补充资料
   不涉及
4. 是否考虑支撑升级和在线扩容等扩展场景
   不涉及
5. 是否考虑异常场景/并发场景/前向兼容/性能场景
   不涉及
6. 是否对其他模块产生影响
   不涉及
   【其他说明】: