in @GlobalTransactional env, SelectForUpdate should acquire lock but not only check lock

## Why you need it?
in @GlobalTransactional env, SelectForUpdate should acquire lock but not only check lock

for an exmple:
global transaction 1(gt1) has 3 steps:
1. select * from t where id=1 for update
2. todo something
3. update t set status=1 where id=1

global transaction 2(gt2) has 1 step:
1. update t set status=3 where id=1

if SelectForUpdate only check lock, then gt2 will run between gt1.step1 and gt1.step3。
so the finally status is 1，but the status expecting is 3.

## How it could be?
gt2 can change the row id=1 only when the gt1 finish.

## Other related information
Add any other context or screenshots about the feature request here.

No implementation files or tests are named. Start by locating Seata's Java handling for SelectForUpdate in a global transaction, then reproduce the two-transaction sequence described in the issue; done requires the second transaction to wait until the first finishes and a regression test to verify the final status.

Written by the indexing model from the issue text.