Support TiKV API V2

[pingyu]

Feature Request

Describe the feature you'd like:

Support TiKV API V2, to obtain more TiKV features such as "cross cluster replication", mixed using TiDB + TxnKV + RawKV on the same TiKV cluster, etc.
See API V2 proposal and its implementation details for detail.
Refer to tikv/tikv#10938.

Teachability, Documentation, Adoption, Migration Strategy:

Some developing features (including "Cross Cluster Replication", mixed using TiDB + TxnKV + RawKV) of TiKV depends on API V2.
We also recommend that users switch to API V2 ASAP, as most features in the future will also be based on API V2.
Data migration is required, as underlying data encoding between API V2 and the early version is quite different. Tools for migration will be provided in the near future.

Modification Required:

1. Set api_version = 2 in kvrpcpb.Context.
2. Prefix requesting keys by r for RawKV, and x for TxnKV.
3. Request region info from PD with keys having r/x prefix and Mem-comparable Padding.
4. Remove prefix of keys from the response if any (e.g. raw_scan, scan).

[iosmanthus]

@pingyu Why do we need to add a prefix to request keys? AFAIK, the keyspace design is cancelled, the mode prefix could be added on the server-side.

[pingyu]

AFAIK the keyspace design is not cancelled but delayed T_T
Moreover, client still need the key prefix when asking PD for region info. So inserting the prefix is unavoidable.

And it just remind me that, should we reserve a byte in key prefix as meta for future ? @zz-jason @andylokandy PTAL~

[zz-jason]

@pingyu could you elaborate more about the possible usages of this reserved byte?

[pingyu]

The possible usages what I can think of now is the "keyspace" :)
Maybe the field can also used for unified querying with multiple TiKV clusters.

And I think the most important thing about the reserved byte is that, it make the key extensible. It can be used as a meta, by indicating more fields via the bits. Which helps to avoid backward-incompatible, if some day we have to encode some extra fields into the key.

[pingyu]

AFAIK the keyspace design is not cancelled but delayed T_T Moreover, client still need the key prefix when asking PD for region info. So inserting the prefix is unavoidable.

And it just remind me that, should we reserve a byte in key prefix as meta for future ? @zz-jason @andylokandy PTAL~

We will not reserve a byte in key prefix. But key prefixes other than r and x will be reserved for future use.

[github-actions]

This issue is stale because it has been open 30 days with no activity.