What this PR does / why we need it:
解决自动化测试时由于多线程并发调用init_gauss_cluster_config导致coredump

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #I3S73S:数据库coredump

Special notes for your reviewer:
【问题现象】：自动化测试时发生coredump，每个core的堆栈都不一样，最终core的位置也不一样，但有个共同的函数是init_gauss_cluster_config

【问题原因】：

1. 原syncrep.cpp中的check_synchronous_standby_names函数中存在如下判断：
   if (strcmp(u_sess->attr.attr_common.application_name, "gsql") == 0 && has_static_config()
   && 0 == init_gauss_cluster_config()) {
   本意的逻辑是限制只有使用gsql连接到数据库通过alter system set synchronous_standby_names的方式配置synchronous_standby_names参数时才会走init_gauss_cluster_config

2. 但通过添加调试日志发现正常运行时如果有gsql修改其他配置项的测试用例，会影响其他的业务线程都会调到这个逻辑里,下面是添加了调试日志的截图：
   2021-06-02 11:56:30.774 60b6fafd.5080 postgres 140154450671360 gsql 0 dn_6001_6002_6003 00000 0 [BACKEND] LOG: [in check_sync_name]applname:gsql, procname:JobScheduler, role:9
   2021-06-02 11:56:30.775 60b6fafd.5067 postgres 140154200626944 gsql 0 dn_6001_6002_6003 00000 0 [BACKEND] LOG: [in check_sync_name]applname:gsql, procname:getpercentile, role:29
   2021-06-02 11:56:30.776 60b6fafd.5069 postgres 140154217408256 gsql 0 dn_6001_6002_6003 00000 0 [BACKEND] LOG: [in check_sync_name]applname:gsql, procname:WDRSnapshot, role:30
   2021-06-02 11:56:30.777 60b6fafd.5065 postgres 140154167064320 gsql 0 dn_6001_6002_6003 00000 0 [BACKEND] LOG: [in check_sync_name]applname:gsql, procname:Statement flush thread, role:32
   2021-06-02 11:56:30.777 60b6fafd.5068 postgres 140154183845632 gsql 0 dn_6001_6002_6003 00000 0 [BACKEND] LOG: [in check_sync_name]applname:gsql, procname:ASP, role:31

从上面可以看到1s内最多时有5到6个线程同时调用init_gauss_cluster_config，同时对里面的全局变量g_node进行free/fread/malloc的操作，故造成概率性的coredump

【修改方案】：
添加判断条件，限制t_thrd.role=WORKER(1)，业务线程的role在初始化完成后都会赋值，不会是1，只有手动的gsql连过来才是1