feature:[loom] replace the usages of synchronized with ReentrantLock

[lightClouds917]

• I have registered the PR changes.

Ⅰ. Describe what this PR did

To use virtual threads in JDK 21, we need to remove the usage of synchronized to prevent the issue where "a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier."

There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:

When it executes code inside a synchronized block or method, or When it executes a native method or a foreign function.
Pinning does not make an application incorrect, but it might hinder its scalability. If a virtual thread performs a blocking operation such as I/O or BlockingQueue.take() while it is pinned, then its carrier and the underlying OS thread are blocked for the duration of the operation. Frequent pinning for long durations can harm the scalability of an application by capturing carriers.

The scheduler does not compensate for pinning by expanding its parallelism. Instead, avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use java.util.concurrent.locks.ReentrantLock instead. There is no need to replace synchronized blocks and methods that are used infrequently (e.g., only performed at startup) or that guard in-memory operations. As always, strive to keep locking policies simple and clear.

You can refer to the following documents:

https://openjdk.org/jeps/444
https://openjdk.org/projects/loom/

Ⅱ. Does this pull request fix one issue?

fixes #6971

This pr does not include the saga module.

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

[codecov]

Codecov Report

Attention: Patch coverage is 57.31707% with 35 lines in your changes missing coverage. Please review.

Project coverage is 52.61%. Comparing base (dc08160) to head (13daa81).

Files with missing lines	Patch %	Lines
...ache/seata/rm/datasource/xa/ConnectionProxyXA.java	43.33%	28 Missing and 6 partials ⚠️
...ache/seata/rm/datasource/xa/ResourceManagerXA.java	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x    #7073      +/-   ##
============================================
+ Coverage     52.58%   52.61%   +0.02%     
- Complexity     6681     6688       +7     
============================================
  Files          1131     1132       +1     
  Lines         40277    40297      +20     
  Branches       4723     4726       +3     
============================================
+ Hits          21179    21201      +22     
+ Misses        17072    17071       -1     
+ Partials       2026     2025       -1     

Files with missing lines	Coverage Δ
...ava/org/apache/seata/common/lock/ResourceLock.java	100.00% <100.00%> (ø)
...va/org/apache/seata/common/util/UUIDGenerator.java	66.66% <100.00%> (ø)
.../integration/tx/api/fence/hook/TccHookManager.java	78.94% <100.00%> (ø)
.../tx/api/remoting/parser/DefaultRemotingParser.java	92.72% <100.00%> (+0.13%)	⬆️
...pache/seata/integration/tx/api/util/ProxyUtil.java	68.18% <100.00%> (+1.51%)	⬆️
...org/apache/seata/rm/datasource/util/JdbcUtils.java	8.34% <100.00%> (-0.07%)	⬇️
...a/integration/rocketmq/SeataMQProducerFactory.java	87.50% <100.00%> (+6.25%)	⬆️
...org/apache/seata/server/session/GlobalSession.java	69.85% <100.00%> (+0.11%)	⬆️
...ache/seata/rm/datasource/xa/ResourceManagerXA.java	21.21% <66.66%> (+0.31%)	⬆️
...ache/seata/rm/datasource/xa/ConnectionProxyXA.java	57.77% <43.33%> (+0.80%)	⬆️

... and 3 files with indirect coverage changes

[YvCeung]

Maybe not including * when importing the package would be more in line with programming standards.

[lightClouds917]

Maybe not including * when importing the package would be more in line with programming standards.

done

[lightClouds917]

The files below saga are handled separately by another pr.

[lightClouds917]

The changes to this class are the synchronized removal of methods and the addition of a try in the code (resourceLock ignored = Resourcelock.obtain ()).
There are more changes here because after adding try, the internal code format is indented