Stale rows might be returned in SelectForUpdateExecutor?

Pseudocode of SelectForUpdateExecutor.doExecute:
```
conn.setAutoCommit(false);
SavePoint sp = conn.setSavePoint();
ResultSet rs = excuteQuery(theBusinessSql); // do business sql (select for update)
while (true) {
try {
tryAcquireGlobalLock();
break; // locked
} catch (THrowable e) {
conn.rollback(sp);
}
}
return rs;
```
When it's failed to acquire global lock, the connection is rolled back to the save point, and the lock(at db level) acquired by business sql will be released, now another transaction may change the rows that matches the business sql, At the time current transaction acquired lock, since we will not execute the business sql again, the stale rows will be returned.

I think the business sql should be executed inside the loop(before acquire global lock)

Start by locating SelectForUpdateExecutor.doExecute and tracing how the business SQL ResultSet, save point rollback, and global-lock acquisition interact. Reproduce the failed-lock and concurrent-update sequence, then verify that the returned rows are current after lock acquisition and add a regression test for the scenario.

Written by the indexing model from the issue text.