fix(java): ThreadPoolFury and ThreadLocalFury concurrency security issue

[LiangliangSui]

What does this PR do?

Fix potential thread safety issues with ThreadPoolFury and ThreadLocalFury.

Related issues

#1524

Does this PR introduce any user-facing change?

• Does this PR introduce any public API change?
• Does this PR introduce any binary protocol compatibility change?

Benchmark

[chaokunyang]

This method should not be called concurently, users should invoke regitster and other fury config methods when creating ThreadSafeFury. It's not necessary to add a lock

[LiangliangSui]

In fact, all our register and config functions should be called when ThreadSafeFury is being created, but the purpose of adding the processCallback function should be contrary to this design. The processCallback interface allows register or config operations to be performed after created ThreadSafeFury.

[LiangliangSui]

ThreadSafeFury safeFury = Fury.builder()
    .requireClassRegistration(true)
    .buildThreadSafeFury();
safeFury.register(A.class);
safeFury.register(B.class);

// Thread A
new Thread(() -> {
  safeFury.serialize(new A());
}).start();

// Thread B
new Thread(() -> {
  // processCallback(fury -> fury.register(clz));
  safeFury.register(C.class);
  safeFury.serialize(new C());
}).start();

As shown in the above Demo, how can we avoid safeFury.register(C.class) being called in Thread B.

[chaokunyang]

Then we should add code to avoid this, such as capture Thread, and check thread in later call

[LiangliangSui]

I think this is a feasible approach, but I think the methods that implement the ThreadSafeFury interface should be thread-safe, and all methods in ThreadSafeFury should be allowed to be called in any thread.

[chaokunyang]

If we allow register classes currently, we do need to make those methods Thread safe.
But it's complex that we register some classes, serialize some objects, Then serialize other classes