To support Virtual Thread, replace synchronized with ReentrantLock.

[InforBG]

Issue #115

Description of changes:
To support Virtual Thread, replace synchronized with ReentrantLock in SecretCacheObject.java.

Please see the document about virtual thread.
https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-04C03FFC-066D-4857-85B9-E5A27A875AF9

A current limitation of the implementation of virtual threads is that performing a blocking operation while inside a synchronized block or method causes the JDK's virtual thread scheduler to block a precious OS thread, whereas it wouldn't if the blocking operation were done outside of a synchronized block or method.
If these mechanisms detect places where pinning is both long-lived and frequent, replace the use of synchronized with [ReentrantLock](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html) in those particular places (again, there is no need to replace synchronized where it guards a short lived or infrequent operations).

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[simonmarty]

Thanks for the contribution. Looks like our internal cache implementation will also have to be updated.

Besides that, we'll need to run a load test to ensure this doesn't impact performance on Java versions < 21

[simonmarty]

I haven't had the opportunity to explore how Virtual Threads work, does the regular Thread class sleep() call still work the same way with them?

[InforBG]

The regualar Thread.sleep() still works here. I tested it and didn't find problem.
The problem only occurs when the synchronized block has blocking operation.
You can reproduce the issue in Linux environment with the code in #115.

[InforBG]

Thanks for the contribution. Looks like our internal cache implementation will also have to be updated.

Besides that, we'll need to run a load test to ensure this doesn't impact performance on Java versions < 21

I think the internal cache implementation doesn't need to be updated. They are all about the map and not blocking operation.
According to https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-04C03FFC-066D-4857-85B9-E5A27A875AF9, Guarding short-lived operations, such as in-memory operations, or infrequent ones with synchronized blocks or methods should have no adverse effect.

That's good idea to run a load test.