store/tikv: fix bug strip keys cause primary key change during prewrite and commit

[tiancaiamao]

What problem does this PR solve?

Problem Summary:

This bug is introduced in #14968

We use the first key in the mutations as the primary key, after stripNoNeedCommitKeys,
the first key of the mutations may be striped and primary key change!

Prewrite and commit use the different primary key could lead to serious bug.
For example:

• txn1 prewrite the data
• txn2 meet txn1's lock, and resolve lock success
• txn1 do not know it is rollbacked (because the pk change), commit (fake) primary key success
• txn1 commit secondary keys fail (some keys rollbacked by txn2)

Part of the transaction is success and part of it fail, leads to data corruption.
This kind of log occures in the log:

2PC failed commit key after primary key committed

What is changed and how it works?

What's Changed:

Specify the primary key in initKeysAndMutations.
Choose the first non-"Delete your write" key as the primary key.

How it Works:

If primary() function find primaryKey is set in the commiter, it use the primaryKey instead of mutations[0].

Related changes

• Need to cherry-pick to the release branch

Check List

Tests

• Unit test

Release note

• Fix a bug that delete previous written values within the same transaction may lead to data corruption.

[tiancaiamao]

Fixed by #18244 already