[improvement](cloud) Use rendezvous hashing for colocate tablet placement (#64638)

[deardeng]

pick from #64638

In cloud mode, colocate tablet-to-BE placement used modulo hashing ((murmur3(grpId) + idx) % availableBeNum), so scaling a compute group up or down remapped almost all buckets and caused large cold-cache query jitter for colocate tables.

Replace it with rendezvous (HRW) hashing behind a new enable_cloud_colocate_consistent_hash (default true): each bucket picks the BE with the highest score(grpId, idx, beId). This keeps the colocate invariant (the same bucket index of all member tables lands on the same BE) while moving only ~1/N buckets when a single BE is added or removed. The legacy modulo path is kept as a rollback branch.

Placement is memoized per (group, compute group) in CloudSystemInfoService with a lock-free cache hit and an order-independent fingerprint of the available BE set for invalidation. The cache is local-only (no editlog, no image), and the dead-BE grace window keeps its existing semantics.

Add unit tests (movement ratio vs modulo, tie-break, cache invalidation, order independence, modulo rollback) and a cloud docker regression case for colocate join correctness.

(cherry picked from commit 355ede4)

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