【标题】(请简要描述下实现的内容)
将load library时的mutex lock改为rdlock，提升并发性
【实现内容】:
将load library时的mutex lock改为rdlock，提升并发性
【根因分析】:
当前加载外部library时，通过 internal_load_library 加载so，并执行 pg_init 等初始化动作，期间需要访问和修改修改全量变量 file_list，为了避免多个会话同时加载so导致同时修改 file_list，所以前面加了mutex互斥锁，使得同一时刻只有一个会话能修改 file_list，其他人需要等待，但这导致整个访问 internal_load_library 存在并发限制。继续分析 internal_load_library 的代码可知，实际上这部分逻辑是可以分成访问file_list（读）和修改file_list（写）两类场景，提升并发度。
另外当前还有一个 dlerror_lock，也是mutex锁，分析代码可知其功能其实和 file_list 有部分重复的，看代码原来应该是想用 dlerror_lock 来控制 file_list 和 CFuncHash 两个全局变量的，后面又加了一个 file_list，单独控制 file_list。所以两个锁实际上有些重复。但本次暂不做大范围修改，只把mutex根据实际情况换成rwlock，分别加读写锁，暂时不考虑重新划分 dlerror_lock 和 file_list_lock 两个锁的控制范围。

【实现方案】:
当前访问 file_list 是典型的读多写少场景，可以使用 pthread_rwlock_t 替换 pthread_mutext_t ，区分访问 file_list 的场景，对于修改场景使用写锁控制，对于访问的场景使用读锁控制，使得读锁场景可以并发执行。这样对于B库dolphin场景，全局实际上只有第一次加载dolphin插件时，需要加写锁做并发控制，后续绝大部分情况下都是读的情况，只需要加读锁即可

• delete_file_handle ，需要修改file_list，全程加写锁，但实际调用场景少
• internal_delete_library， 需要修改file_list，全程加写锁，但实际调用场景少
• internal_load_library， 读取file_list时加读锁，修改file_list时加写锁，修改的调用场景少，读取的调用场景多，主要优化点
• internal_unload_library， 需要修改file_list，全程加写锁，但实际调用场景少
• InitExtensionVariable， 需要读取file_list，全程加读锁，线程初始化时会调用一次，调用场景一般

dlerror_lock 的修改和 file_list_lock 类似，不再赘述，也是根据实际使用场景，分别获取读锁、写锁。同时参考 AutoMutexLock 实现 AutoRWLock 类，用于封装对 pthread_rwlock_t 的加锁和释放

【关联需求或issue】:
https://gitcode.com/opengauss/Plugin/issues/1521

【开发自验报告】:

1. 请附上自验结果(内容或者截图)
   优化前，B库B协议 sysbench 128并发，read only， 33.7 W QPS
   
   优化后，B库B协议 sysbench 128并发，read only， 34.8W QPS
   

优化前，B库A协议 TPCC 88~89W左右（基线值）。优化后，B库A协议 TPCC 117W

2. 是否可以添加fastcheck测试用例，如是，请补充fastcheck用例
   否，对外表现无变更
3. 是否涉及资料修改，如是，在docs仓库补充资料
   不涉及
4. 是否考虑升级场景(系统表修改、日志持久化以及修改执行态数据格式)
   不涉及
5. 是否考虑在线扩容等扩展场景
   不涉及
6. 是否考虑异常场景/并发场景/前向兼容/性能场景
   不涉及
7. 是否对其他模块产生影响
   不涉及
8. 是否需要回合补丁版本(5.0、6.0)，涉及(结果错误|coredump|性能劣化|内存泄露|集群异常)相关修复请排查回合补丁分支
   不涉及

【其他说明】: