AT 模式下 ，怎样的流程才能让TC端的全局事务状态变为TimeoutRollbackRetrying ？

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

### Ⅰ. Issue Description

seata源码1.6.1，我现在梳理的情况同步一下：
1. 事务超时是被【timeout】定时任务检测到之后将 `Begin` 状态修改为 `TimeoutRollbacking`
2. 在【retryRollbacking】定时任务 中，会拉取 `TimeoutRollbacking` 状态的事务，进行回滚
3. 但【retryRollbacking】的 定时任务 调用 `doGlobalRollback(...)`这个方法执行回滚时，retrying 参数给的是true，不触发其内部的`queueToRetryRollback(...)`方法

5. 但从源码梳理来看，只有进入`queueToRetryRollback`方法，才会将 `TimeoutRollbacking` 状态转换到 `TimeoutRollbackRetrying`，
```
public void queueToRetryRollback() throws TransactionException {
this.addSessionLifecycleListener(SessionHolder.getRetryRollbackingSessionManager());
GlobalStatus currentStatus = this.getStatus();
// 这里 将 `TimeoutRollbacking` 状态转换到 `TimeoutRollbackRetrying`
if (SessionStatusValidator.isTimeoutGlobalStatus(currentStatus)) {
this.setStatus(GlobalStatus.TimeoutRollbackRetrying);
} else {
this.setStatus(GlobalStatus.RollbackRetrying);
}
SessionHolder.getRetryRollbackingSessionManager().addGlobalSession(this);
}
```
6. 所以看起来并不满足进入`queueToRetryRollback(...)`方法的条件

Start with the timeout and retryRollbacking scheduled-task paths described in the issue, then trace the doGlobalRollback(...) and queueToRetryRollback(...) entry points. Compare the status transitions and retrying argument in the cited source. Done means documenting or reproducing the path that reaches TimeoutRollbackRetrying, or confirming the transition cannot occur as described.

Written by the indexing model from the issue text.