sink to mysql (ticdc) conflict detector has potential dead lock when a single transaction generate multiple same hashes

[zhangjinpeng87]

The conflict detector is used to construct dependency graph (DAG). Each transaction has a related node in the DAG. Each transaction may contains multiple rows, each row may has multiple keys need to check conflict in the DAG because related table may have unique indices:

table (a, b, c, d, primary(a, b), unique index(b, c));

When TiCDC check the conflict between a new transaction and existing transactions, TiCDC need to construct primary key and all unique key hashes for each rows. Let's use the above table as an example, each row will generate 2 hashes, one for primary key(a, b), one for unique index(b, c). This transaction use these hashes to join into the existing dependency graph, and calculating potential conflicts with existing transactions.

https://github.com/pingcap/tiflow/blob/master/pkg/causality/worker.go#L28 should generate deduplicated hashes for a transaction, but https://github.com/pingcap/tiflow/blob/master/cdc/sink/dmlsink/txn/event.go#L45-L48 doesn't dedup hashes for the transaction. This may cause self cyclic dependency in the DAG which cause dead lock issue (the conflict detector blocked on this transaction, and changefeed checkpoint ts stack).