Tracking issue for scale-out single large table to multiple TiCDC instances

[overvenus]

This project add the ability of scale-out of a single table to multiple TiCDC nodes. Let TiCDC support dynamically split and merge spans based on statistical data, including region count, write throughput, etc. Split and merge are just table scheduling, and with the help of two-phase scheduling, they have minimal impact on replication latency.

Span Replication

• processor,pkg(ticdc): add Span and package spanz #7722
• scheduler(ticdc): add compat layer #7723
• scheduler(ticdc): add package keyspan  #7731
• cdc: replace tableID with Span in TableExecutor and agent  #7793
• scheduler(ticdc): replace tableID with Span #7806
• puller,processor: replace table ID with Span  #7832
• sorter/db,processor: replace table ID with Span  #7833
• sinkv2,processor: replace table ID with Span #7838
• pkg(ticdc): merge package regionspan and spanz #7880
• ticdc: disable span replication in mysql/tidb changefeed  #7909
• redo(ticdc): replace tableID with Span #7916
• processor(ticdc): replace tableID with Span in sourcemanager and sinkmanager #7978
• scheduler(ticdc): optimize owner memory allocation #8010
• Unify variable names, rename table to tableSpan
• cdc: replace BtreeMap with HashMap in TiCDC  #8021
• scheduler(ticdc): split more evenly #8070
• config(ticdc): move region-per-span to changefeed config #8100

Support split span by write throughput

• scheduler(ticdc): split span by region written keys #8496
• scheduler(ticdc): add splitter interface #8505

Document

• ticdc: add scale out for kafka changefeed docs-cn#12693
• ticdc: update changefeed scheduler configs docs-cn#13341
• ticdc: update scale out config docs-cn#13578