Decide the behavior of Insert/CheckNotExist followed by Delete

[ekexium]

Quote from #253 :

CheckNotExist was introduced for TiDB to simulate MySQL like behavior in optimistic transactions. I am truly not sure what users expect under "insert and delete". Is there a case people expect commit not to fail under this case?

Possible solutions:

1. Insert + Delete => CheckNotExist
   1.1 CheckNotExist + Delete => CheckNotExist
   1.2 CheckNotExist + Delete => Delete (current behavior)
2. Insert + Delete => Delete. CheckNotExist is not needed then.
3. Check the existence immediately at the Insert (possibly by a Get and a Put), instead of at the commit

[ekexium]

I feel like 1.1 is the most intuitive. What do you think? @nrc @sticnarf @andylokandy

[sticnarf]

1.2 is certainly not reasonable behavior..

[ekexium]

Agree

[sticnarf]

Option 4: Insert + Delete => NoOp. Contrary to 2, the key does not cause a WriteConflict.

[nrc]

Is there behaviour in TiDB we should be aligned to? Or if TiDB used the Rust client, what behaviour would be expected?