When retryPolicyBranchRollbackOnConflict set to true, the TC spawn logs frequently

- [ ] I have searched the [issues](https://github.com/seata/seata/issues) of this repository and believe that this is not a duplicate.

### Ⅰ. Issue Description
When the TC survivable self-test switch is turned on, the TC will simulate the global transaction opening and submission of each client in a self-test cycle, resulting in a large number of simulated transaction logs being frequently flushed by the TC side, resulting in the TC side log being too large, and affecting the normal troubleshooting by viewing the TC log.

### Ⅱ. Describe what happened
A large number of simulated transaction logs appear on the TC side
If there is an exception, please attach the exception trace:

```
Just paste your stack trace here!
```15:09:25.752 INFO --- [verHandlerThread_1_41_500] i.s.s.coordinator.DefaultCoordinator : Begin new global transaction applicationId: shop-order-application,transactionServiceGroup: local_group, transactionName: degradeCheck,timeout:60000,xid:192.168.10.7:18091:92637771075686400
15:09:25.757 INFO --- [ batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler : SeataMergeMessage xid=192.168.10.7:18091:92637771075686400,extraData=null
,clientIp:192.168.10.68,vgroup:local_group
15:09:26.698 INFO --- [ AsyncCommitting_1_1] io.seata.server.coordinator.DefaultCore : Committing global transaction is successfully done, xid = 192.168.10.7:18091:92637771075686400.
15:10:03.774 INFO --- [ batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler : SeataMergeMessage timeout=60000,transactionName=createByAT()

### Ⅲ. Describe what you expected to happen

Hopefully the TC will not spawn these logs
### Ⅳ. How to reproduce it (as minimally and precisely as possible)
1. Retrypolicybranchrollbackonconflict is set to true
2. Observe TC log

### Ⅴ. Anything else we need to know?
It is recommended to set the mock log level to DEBUG

### Ⅵ. Environment:

- JDK version :1.8
- OS :CentOS
- Others: