information_schema.deadlocks incorrectly collects retryable deadlocks as if it's non-retryble

[MyonKeminta]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

1. Construct a scenario where retryable (single-statement) deadlocks occurs.
2. Check information_schema.deadlocks for the information of the retryable deadlock.

2. What did you expect to see? (Required)

When the config pessimistic-txn.deadlock-history-collect-retryable is not enabled, there shouldn't be information about it; otherwise, there is a deadlock information about it with retryable column be 1.

3. What did you see instead (Required)

In both case the deadlock information shows up, and retryable column is always 0.

The reason is that client-go invokes a callback from TiDB to collect the deadlocks, but it's invoked prior to the IsRetryable field being set.

4. What is your TiDB version? (Required)

master, 5.2, 5.1

[ti-srebot]

Please edit this comment or add a new comment to complete the following information

Bug

Note: Make Sure that 'component', and 'severity' labels are added
Example for how to fill out the template: #20100

1. Root Cause Analysis (RCA) (optional)

TiDB uses a callback OnDeadlock for collecting deadlock information to information_schema.deadlocks, however the callback is called before checking if the deadlock is retryable and set the IsRetryable field, therefore the retryable deadlocks are all considered ad non-retryable ones.

2. Symptom (optional)

Retryable deadlocks are collected to information_schema.deadlocks as if they are non-retryable ones, with RETRYABLE column be 0.

3. All Trigger Conditions (optional)

None

4. Workaround (optional)

None

5. Affected versions

[v5.1.0:v5.1.1]

6. Fixed versions

v5.1.2

[ti-srebot]

The values in ( FixedVersions ) fields are incorrect.