[improvement](fe) Share CloudReplica route identifiers (#68783)

[deardeng]

pick from #68783
Related PR: #67636
Problem Summary: CloudReplica image deserialization created independent String cluster IDs and boxed Long backend IDs for equivalent routes. The tested production image contains 4,197,906 replicas and 62,708,955 routes but only 15 cluster IDs and about 85 backend IDs, so millions of equal route identifiers retained duplicate heap objects. Canonical sharing reduced forced-GC live heap from 15,311,045,744 bytes to 8,539,550,968 bytes, saving 6,771,494,776 bytes (6.31 GiB, 44.2%).

Intern cluster IDs and primary backend IDs on route updates and after image deserialization so equal routes reuse the same objects. Use Guava weak interners instead of strong process-lifetime maps: active routes keep canonical objects alive, while identifiers become collectable after their last route is removed. Routing behavior and the serialized image format are unchanged.

The full 6.93 GB image completed compatibility load and dump with the final weak-interner implementation. A clean run loaded in 225.679 seconds and dumped in 145.935 seconds. JFR attributed 255 of 18,139 load-stage CPU samples (1.41%) to the interner path, with no sampled allocations attributed directly to it.

Reduce FE heap usage for CloudReplica routing metadata and release unused historical route identifiers.

• Test: Unit Test / Manual test
  • CloudReplicaTest: 23 tests passed
  • ./build.sh --fe passed with Checkstyle 0 violations
  • Full production image compatibility load and dump passed
  • JFR profile verified the interner path is not a load hotspot

(cherry picked from commit 818d3f6)

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[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?

[deardeng]

run buildall

[hello-stephen]

FE UT Coverage Report

Increment line coverage 100.00% (10/10) 🎉
Increment coverage report
Complete coverage report

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 100.00% (10/10) 🎉
Increment coverage report
Complete coverage report