Tracking issue for sink returning inaccurate checkpoints

[overvenus]

In the current implementation (11/20/2021), when a table flushes its' sink, sink may return a checkpoint that is larger than resolved ts.
It can easily be reproduced when tables in a "slow" TiCDC node, whose checkpoint is Tca, are scheduled to a "faster" TiCDC node, whose checkpoint is Tcb, and Tca < Tcb .

Combine with #3029 and #2617, it can easily cause data lose and changefeed stuck when a "slow" is killed, e.g.,

• Buggy sink returning a checkpoint that is too large can cause flow control to dead-lock #3531
• Case "cdc_minor_components_unavaible" failed because changefeed stuck #3521
• [ticdc 5.3.0] tikv_scale_plan_tidb case fail: 1. cdc oom, 2. data inconsistency, 3. changefeed stuck #3503

Sink must return accurate checkpoint for each table. It is hard to implement with the current interface design, especially when a sink is shared by multiple tables.

PRs：

• cdc/sink: Refine sink interface #3613
• cdc/sink: Sink manager manage checkpoint per table #3621
• cdc/sink: buffer sink manage checkpoint ts per table #3625
• cdc/redo: redo applier flush resolvedTs per table #3638
• cdc/sink: mysql sink manage checkpoint per table #3645
• mq (ticdc): mq sink manage checkpoint ts per table  #3746

[overvenus]

Change to severity/moderate, as most issues are fixed.

[asddongmen]

@overvenus I think we can close this issue as a result of all the fix PR have been merge.