[opt](point query) use fastUniqueId instead of UUID.randomUUID to reduce contention

[HonestManXin]

"mysql-nio-pool-52" #340 daemon prio=5 os_prio=0 tid=0x00007f3ac801d800 nid=0x3e35cd waiting for monitor entry [0x00007f39742d7000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:215)
	- waiting to lock <0x00007f3f9c218f58> (a sun.security.provider.SecureRandom)
	at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:534)
	at sun.security.provider.NativePRNG$RandomIO.access$400(NativePRNG.java:331)
	at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:220)
	at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
	at java.util.UUID.randomUUID(UUID.java:145)
	at org.apache.doris.qe.StmtExecutor.execute(StmtExecutor.java:555)
	at org.apache.doris.qe.MysqlConnectProcessor.handleExecute(MysqlConnectProcessor.java:246)
	at org.apache.doris.qe.MysqlConnectProcessor.handleExecute(MysqlConnectProcessor.java:294)

In high‑concurrency point‑query scenarios, a large number of requests require generating a UUID for internal identification. When the request rate is high, frequent calls to UUID.randomUUID() can introduce contention and become a minor performance bottleneck.

For query, the UUID is only required to provide a unique identifier for request correlation, and cryptographic strength is not necessary. To reduce contention and improve throughput, this change introduces fastUniqueId, which generates RFC‑4122 compatible UUID v4 values using ThreadLocalRandom.

By using a per‑thread random generator instead of the shared random source used by UUID.randomUUID(), UUID generation scales better under high concurrency while still preserving the standard UUID format.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[HonestManXin]

/review

[HonestManXin]

run buildall

[github-actions]

Review result: no blocking issues found in this PR. The change replaces FE query-id generation in StmtExecutor with a ThreadLocalRandom-based UUID v4-compatible TUniqueId generator, which matches the stated goal of avoiding SecureRandom contention for non-security request correlation IDs.

Critical checkpoint conclusions:

• Goal and tests: The implementation addresses the stated contention source in StmtExecutor query-id generation. Existing CI CheckStyle passed, and I also ran mvn -pl fe-core -DskipTests -Dskip.doc=true checkstyle:check successfully. No dedicated UUID utility unit test is added; residual risk is low because the bit layout is straightforward and mirrors UUID v4 masking.
• Scope: The modification is small and focused: one utility class plus replacements at query/retry/internal-query id generation sites.
• Concurrency: This path is concurrency-related by design. Using ThreadLocalRandom removes the shared SecureRandom monitor contention from these call sites; no shared mutable state or new lock ordering is introduced.
• Lifecycle/static initialization: The SecureRandom holder is lazy and only used by the secure fallback helper, not by the new hot path. No cross-TU/static initialization concern applies in Java here.
• Configuration: No configuration items are added.
• Compatibility/storage format: Generated IDs remain 128-bit TUniqueId values with UUID v4 version/variant bits; no storage, RPC, or mixed-version protocol format change is introduced.
• Parallel paths: The PR updates the StmtExecutor query-id generation sites related to the reported query execution path. Other UUID.randomUUID uses appear to be labels/session IDs/tests and are outside this specific non-cryptographic query-id scope.
• Conditional checks: No new special conditional logic is added.
• Test coverage/results: No result files are changed. CheckStyle passed locally; broader FE UT/compile/performance checks were still pending in GitHub/TeamCity when reviewed.
• Observability: Existing query-id logging/audit behavior is preserved through DebugUtil.printId(TUniqueId). No additional metrics/logs appear necessary.
• Transaction/persistence/data writes: The reviewed changes do not modify transaction, persistence, or data write semantics.
• FE-BE variable passing: No new transmitted field is added; existing TUniqueId propagation is preserved.
• Performance: The hot-path contention issue is improved without obvious added allocation beyond the existing TUniqueId object.

User focus: no additional user-provided review focus was present.