tests/integration: Update TestLeasingDeleteRangeContendTxn

[fuweid]

The TestLeasingDeleteRangeContendTxn is trying to test for RangeDelete when the target resources are being updated. When the txnLeasing wants a server-side transaction, it needs to ensure all the keys mod revision should be leass than what it saw. If the compare fails, it will repeat to apply the server-side transaction until it is sucessful. I believe the test-case is trying to verify how the txnLeasing handles the race issue.

Before the patch #15401, the resource-updating goroutine keeps updating until the RangeDelete finishes. The testcase is flaky because two goroutines are sharing one ctx and grpc-go client won't wait for the response if ctx has been canceled.

For example,

DelLease Goroutine	PutLease Goroutine	ETCD Server	Key/0 Status
deleted			version = 0
	send update(key/0=123) req	received update(key/0=123) req	version = 0
cancel			version = 0
	exit because of cancel		version = 0
get key/0 by putkv			version = 0
		applied update(key/0=123)	version = 1
get key/0 by raw-cli			version = 1

So raw-cli gets [key/0=123] while the putkv gets []. If putkv applies two update reqs to ETCD server and the last one is canceled before apply, the error will be like:

expected [key:"key/0" version:2 value:"123" ], got [key:"key/0" version:1 value:"123" ]

The resource-updating goroutine should not share the ctx with RangeDelete here. And I also revert current main branch because the resource-update goroutine only updates 8 times and might exit before RangeDelete. In this case, the txnLeasing is not handling the race issue.

Fixes: #15352

Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.

---

cc @ahrtr @chaochn47 @serathius @tjungblu

[tjungblu]

ahh it's the context, not the counter. Great find @fuweid!

[ahrtr]

Good catch, thank you @fuweid

I really like such fix for flaky test.