*: add low latency performance mode

[asddongmen]

What problem does this PR solve?

Issue Number: close #xxx

TiCDC timestamp propagation is tuned for throughput. Fixed batching and heartbeat intervals add avoidable resolved-ts and checkpoint-ts latency for latency-sensitive deployments.

What is changed and how it works?

• Add performance-mode = "throughput" | "low-latency"; throughput remains the default.
• In low-latency mode, advance puller resolved-ts immediately and batch region heap updates under one lock.
• Shorten dispatcher and maintainer heartbeat intervals, remove the dispatcher startup delay, and wake checkpoint calculation when a newer watermark arrives.
• Flush EventService resolved-ts more frequently.

Six sequential 10-minute E2E rounds used 3 CDC nodes, 32 bank tables, about 10k regions, 2 MiB/s traffic, TiKV cdc.min-ts-interval=200ms, and MySQL dry-run delay 50ms. Mean API lag fell from 1.001s to 0.306s. Step 5 showed no additional latency gain and increased aggregate CDC CPU by 26.8%, so it remains visible for Draft review.

Check List

Tests

• Unit test
• Integration test
• Manual test: six 10-minute remote E2E rounds with resolved/checkpoint latency collection

Questions

Will it cause performance regression or break compatibility?

Default behavior is unchanged. Low-latency mode intentionally trades CPU and message volume for latency; the 5ms EventService flush needs further review.

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

Yes. Document the mode and its resource trade-offs before GA.

Release note

Add an opt-in low-latency TiCDC server mode that advances and reports resolved and checkpoint timestamps more promptly.