This is an automated cherry-pick of #19284

What is changed and how it works?

Issue Number: Close #19285

What's Changed:

Fix a memory leak in crossbeam-skiplist's RefRange iterator.

RefRange::next() and next_back() were using clone_from() to update self.head/self.tail. Since RefEntry has no Drop implementation (by design - callers must explicitly call release()), the old entry was dropped without decrementing its refcount, causing permanent memory leaks.
Note that the the comment of RefEntry says

/// You *must* call `release` to free this type, otherwise the node will be
/// leaked. This is because releasing the entry requires a `Guard`.

This bug affects any code using SkipMap::range() iterators. In TiKV, this manifests as memory leaks in LockTable when check_range() or find_first() are called.

// Before (buggy):
self.head.clone_from(&next_head);  // Old entry dropped without decrement!

// After (fixed):
if let Some(e) = mem::replace(&mut self.head, next_head.clone()) {
    unsafe { e.node.decrement(guard); }  // Properly decrement old entry
}

The fix matches the pattern already used in RefIter::next().

Stress test results (10 seconds, range iteration + insert/remove cycle):

before fix:
t=10s ops=11710 len=3422 alloc=613MB
after fix:
t=10s ops=11786 len=7530 alloc=3MB

Fix RefRange::next() and next_back() to properly decrement old self.head/self.tail refcount.

Related changes

• PR to update pingcap/docs/pingcap/docs-cn:
• Need to cherry-pick to the release branch

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Release note

Fix a memory leak in crossbeam-skiplist's RefRange iterator that caused LockTable memory to grow unboundedly when using range queries.