puller may got stuck in some cases

[lidezhu]

What did you do?

In tikv side, to distinguish connections from different versions of cdc, it maintains a feature list for a every connection.
And tikv use the first request from each connection to set the feature list of the connection.
https://github.com/tikv/tikv/blob/a34740fefaf69092d14f6af5160e8e5ff1c507f8/components/cdc/src/service.rs#L450

If the connection doesn't enable FeatureGate::BATCH_RESOLVED_TS, it won't get any resolved ts message.
https://github.com/tikv/tikv/blob/a34740fefaf69092d14f6af5160e8e5ff1c507f8/components/cdc/src/endpoint.rs#L443

FeatureGate::BATCH_RESOLVED_TS is enabled when the cdc version in the request header is larger than 4.0.8.

But in cdc side, the deregister request's header doesn't have cdc version information. So if the first request of a connection is a deregister request, the connection can never get any resolved ts message.

This problem happens when dispatcher register and deregister happens in a very short time.
Detail steps:

1. A request worker receive a region for sending;
2. Before send, the request worker finds that the region of the table is stopped, so it discards the region;
3. The request worker receives an unregister signal of the table, it sends the deregister request to tikv and tikv disable FeatureGate::BATCH_RESOLVED_TS of the connection, so this connection will never receive any resolved ts.

What did you expect to see?

No response

What did you see instead?

puller never receive any resolved ts message.

Versions of the cluster

Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):

(paste TiKV version here)

TiCDC version (execute cdc version):

(paste TiCDC version here)