Fix two bugs with insert and delete

[nrc]

Fixes #234

PTAL @sticnarf

Previously there were two bugs:

• If the user deletes a key, then inserts a value to the same key, then there will be false positive failure of the insert invariant. This is fixed by converting the insert into a put.
• If the user inserts then deletes a key, the delete is converted into a check that the value doesn't exist. However, if the transaction is pessimistic, TiKV cannot handle that check and the key is left locked (Committing a delete must unlock #234). This is fixed by checking for previous values when we lock the key for insertion, then removing the insert rather than converting it if it is deleted.

[ekexium]

If we consider the buffer as a state machine, there might be several more issues that are worth consideration:

1. Locked + Lock: we don't need to lock again, unless (1) auto_heartbeat disabled (2) value needed but there is no cache
2. CheckNotExist + Delete: should be CheckNotExist

And I think CheckNotExist is a little special one. I suggest we treat it as a normal operation in the buffer, though we don't provide a direct corresponding operation in Transaction. So that for example in

client-rust/src/transaction/buffer.rs

Lines 20 to 22 in 4870985

	if !matches!(entry, BufferEntry::Cached(_)) {
	self.primary_key.get_or_insert_with(|| key.clone());
	}

, we should also exclude CheckNotExist.

[sticnarf]

If we consider the buffer as a state machine, there might be several more issues that are worth consideration:

1. Locked + Lock: we don't need to lock again, unless auto_heartbeat disabled

2. CheckNotExist + Delete: should be CheckNotExist

+1 for "Locked + Lock".

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?

There may also be an alternative that we always check existence inplace at insert instead postponing it until commit.

[sticnarf]

This PR itself looks good. The remaining problems may not be the subject of this PR :)

[ekexium]

LGTM

[nrc]

rust-lang/rust#82608 caused a compiler regression which causes the build to fail (due to spurious errors in the clang-sys crate). I've added a rust-toolchain file to address this temporarily.