feat: Define clone sync criteria in CoordinatorDynamicConfig

[kfaraz]

Description

When cloning historicals for a blue-green deployment using CoordinatorDynamicConfig.cloneServers, it can often be difficult to determine if the clones are already synced and can be safely terminated. This is primarily because the source server keeps getting assigned new segments and the clone target is always playing catch up.

The metric that has been used so far to determine if a clone is sufficiently "synced" is the segmentLoadsRemaining returned by the /cloneStatus API, but that number often fails to fall below any reasonable threshold thereby slowing down the deployment.

Changes

• Add a configurable CloneSyncCriteria to CoordinatorDynamicConfig
• The criteria is a function of segments "pending sync" during a coordinator run i.e. segments which are already loaded on the source server but still loading at the target server at the start of the run.
• If the criteria is met, update the state of the clone to SYNCED and emit a metric
• In subsequent runs, it is possible for the state to go back to IN_PROGRESS if the clone starts lagging behind again

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[FrankChen021]

Severity	Findings
P0	0
P1	2
P2	1
P3	0
Total	3

Reviewed 14 of 14 changed files.

---

This is an automated review by Codex GPT-5.6-Luna(max)

[FrankChen021]

[P1] Allow either sync threshold to qualify

The two configured limits are intersected here, so maxSegmentsPendingSync cannot independently make a clone SYNCED. The new test configures (maxSegmentsPendingSync=1, maxPercentPendingSync=10.0) with nine source segments and one pending segment: the absolute limit is met, but the calculated percentage is 11.11%, leaving the status IN_PROGRESS and contradicting the test's expected SYNCED state. Combine the thresholds according to the documented number-or-percentage semantics (or change the public contract and test).

[FrankChen021]

[P1] Include clone criteria in config equality

The new cloneSyncCriteria field is not included in CoordinatorDynamicConfig.equals() or hashCode(). The existing CoordinatorDynamicConfigTest uses EqualsVerifier without ignoring this field, so the test will reject the class; in production, BaseDynamicConfigSyncer also treats a threshold-only update as unchanged and does not invalidate its inSyncBrokers snapshot. Add value-based equality for the criteria and include it in both config methods.

[FrankChen021]

[P2] Emit the initial SYNCED transition metric

A coordinator starts with no entry in CloneStatusManager, so a clone that already satisfies the criteria on its first run has oldStatus == null. This condition then suppresses Stats.Segments.PENDING_SYNC even though the new state is SYNCED; the added simulation test expects that metric on its initial run. Treat the absent status as a transition (or otherwise emit the metric for the initial qualifying run).

[jtuglu1]

cc @maytasm

[FrankChen021]

Severity	Findings
P0	0
P1	0
P2	2
P3	1
Total	3

Severity	Findings
P0	0
P1	0
P2	2
P3	1
Total	3

Reviewed 16 of 16 changed files.

---

This is an automated review by Codex GPT-5.6-Luna(max)

[FrankChen021]

[P2] Include tier in pending-sync metric

segment/clone/pendingSync/count is documented with server,tier dimensions, and the other clone metrics now include the target tier, but this row key is still server-only. In a multi-tier deployment the emitted event cannot be filtered or grouped by tier and does not match the documented metric contract. Include Dimension.TIER for the target in this row key.

[FrankChen021]

[P2] Do not count skipped segments as pending

getLoadableSegment explicitly returns null for unused segments, so this call can queue no load. The counter is incremented unconditionally after the call whenever the source still serves the segment. An unused segment that remains in the source inventory therefore contributes to segmentsPendingSync and its percentage until it is unloaded, and can keep a clone IN_PROGRESS even though the clone duty intentionally skips that segment. Count it only when the segment is eligible for reconciliation, and cover a served-but-unused source segment.

[FrankChen021]

[P3] Correct dropped-clone metric description

This is the description for segment/clone/dropped/count, but it says segments are assigned to be loaded. The stat is emitted from DROPPED_FROM_CLONE when a drop is queued, so the description should say that segments are assigned to be dropped; otherwise operators will interpret this new metric backwards.