*: make low-latency mode changefeed-scoped

[asddongmen]

What problem does this PR solve?

Issue Number: close #5705

TiCDC's low-latency optimizations were configured per server, so throughput
and latency-sensitive changefeeds could not safely coexist on the same
captures. Resolved-ts observability and high-cardinality EventService scan
scheduling also had avoidable latency and queue pressure.

Supersedes #5749.

What is changed and how it works?

• Move performance-mode to persisted changefeed ReplicaConfig, propagate
  it through dispatcher register/reset messages, and isolate EventStore
  subscriptions by mode.
• Make dispatcher heartbeats, Maintainer wakeups, EventService scan
  continuation, and schema-blocked retry changefeed-scoped. The retry ticker
  starts lazily only after the first low-latency changefeed.
• Defer active-scan lifecycle registration until a worker actually invokes
  the scanner, reducing false queue pressure for no-scan tasks.
• Correct ticdc_owner_resolved_ts_lag to consistently report current PD
  wall-clock age of the coordinator's global minimum resolved timestamp, with
  immediate refresh after complete node-report rounds.
• Preserve concurrent Maintainer status updates across heartbeat snapshots.

Check List

Tests

• Unit test
• Manual test (three captures, two concurrent 100k-table changefeeds, 200k
  isolated subscriptions, 20.245 MB/s shared traffic for 30 minutes; all
  5,203 samples normal/equal. Low-latency owner checkpoint mean/P95/P99:
  0.879/1.059/1.158s; throughput: 1.770/2.358/2.508s.)

Questions

Will it cause performance regression or break compatibility?

Throughput remains the default. Existing configs that omit the field keep
throughput behavior. Opposite modes intentionally do not share EventStore
subscriptions. The 30-minute mixed-mode run passed without status or count
drift; aggregate CPU/RSS was 32.556 cores/25.862 GiB.

Do you need to update user documentation, design documentation or monitoring documentation?

Yes. User documentation for the new changefeed option should be added before
the PR is marked ready. The existing metric name is unchanged; its semantics
are clarified and made consistent.

Release note

Add a changefeed-level performance mode that allows low-latency and throughput
changefeeds to coexist, and reduce resolved-ts propagation latency.

[ti-chi-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign nongfushanquan for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS
• pkg/config/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a85cd703-8947-4196-81df-6603bad445b4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}