Refactor the lock implementation in GlobalClockTransactionHook

[FlyingZC]

Feature Request

Refactor the lock implementation in GlobalClockTransactionHook.

1. Avoid using registry-based locks (e.g., ZooKeeper) because acquiring a lock might timeout in beforeCommit, but the afterCommit could still attempt to release it. Eliminate unnecessary unlock operations.

Corresponding FIXME:

FIXME: If timeout occurs when a lock is required but TSO is not assigned, the commit will still proceed. The solution is to replace the registry center's lock with a Redis-based lock implementation.

2. Move the locking logic to the TSO component (e.g., implement locking/unlocking via Redis's native lock in RedisTSOProvider). Corresponding TODO:

// TODO: Use Redis lock instead of registry center's lock.

[Dltmd202]

Hi, please assign this issue to me. Thank you!

[Dltmd202]

Hi @FlyingZC, I’ve created a refactor PR here: https://github.com/apache/shardingsphere/pull/35842 When you have a moment, could you please take a look?