There are two or more situations in which the region we got is stale. The first case is that the process of getting a region is concurrent. The stale region may be returned later due to network reasons.
The second case is that the region may be obtained from the PD follower in the future, and there is the synchronization time between the pd follower and the leader.
So we should check the epoch to avoid stale region.

Some details of the insertRegionToCache are described as follows.

Firstly, mu.latestVersions[cachedRegion.VerID().id] is used to check if there is an old version with the same ID. If it exists, the code compares the version numbers (newVer.GetVer() and oldVer.GetVer()) as well as the conf version numbers (newVer.GetConfVer() and oldVer.GetConfVer()). If the old version number is higher, it considers the newly obtained Region as stale.

Next, mu.sorted.removeIntersecting is called to check and remove any old Regions that overlap with the new Region, and to determine if the new Region is stale.

Afterward, the new Region is inserted into the cache using the mu.sorted.ReplaceOrInsert(cachedRegion) method.

If there are existing old Regions that overlap with the new Region, it inherits some information from the first overlapping Region, such as working indexes for TiKV and TiFlash, as well as bucket information.

Finally, it iterates over the overlapping old Regions, removes them from the cache, and marks them as expired. If the invalidateOldRegion parameter is true, the old Regions are marked as invalid to prevent certain requests from using expired Region information.

Lastly, relevant variables are updated, including adding the new Region and its corresponding version to mu.regions and mu.latestVersions.

Throughout this process, by comparing version numbers and cluster change version numbers, as well as removing overlapping old Regions, it ensures that the Region information in the cache is up-to-date and valid.

Benchmark test result (count = 20)
InsertRegionToCache tests the case in which the key range and epoch change and delay appear. InsertRegionToCache2 tests the case in which the key range does not change.
master compares this PR

name                    old time/op    new time/op    delta
InsertRegionToCache-8     1.44µs ± 1%    1.34µs ± 1%   -7.24%  (p=0.000 n=17+18)
InsertRegionToCache2-8    1.13µs ±11%    1.12µs ± 0%     ~     (p=0.567 n=18+18)

name                    old alloc/op   new alloc/op   delta
InsertRegionToCache-8       653B ± 1%      765B ± 0%  +17.21%  (p=0.000 n=19+20)
InsertRegionToCache2-8      464B ± 0%      472B ± 0%   +1.72%  (p=0.000 n=20+20)

name                    old allocs/op  new allocs/op  delta
InsertRegionToCache-8       26.0 ± 0%      26.0 ± 0%     ~     (all equal)
InsertRegionToCache2-8      23.0 ± 0%      24.0 ± 0%   +4.35%  (p=0.000 n=20+20)

We can see that the results of the two tests are significantly different. There is no problem in terms of speed, mainly in terms of memory allocation.
To find out why this PR allocates more bytes, I remove the code that checks the intersected region(in sorted_btree.go).

And master compares it.

name                    old time/op    new time/op    delta
InsertRegionToCache-8     1.44µs ± 1%    1.38µs ± 0%   -4.10%  (p=0.000 n=17+16)
InsertRegionToCache2-8    1.13µs ±11%    1.12µs ± 2%     ~     (p=0.625 n=18+19)

name                    old alloc/op   new alloc/op   delta
InsertRegionToCache-8       653B ± 1%      563B ± 0%  -13.74%  (p=0.000 n=19+20)
InsertRegionToCache2-8      464B ± 0%      472B ± 0%   +1.72%  (p=0.000 n=20+20)

name                    old allocs/op  new allocs/op  delta
InsertRegionToCache-8       26.0 ± 0%      26.0 ± 0%     ~     (all equal)
InsertRegionToCache2-8      23.0 ± 0%      24.0 ± 0%   +4.35%  (p=0.000 n=20+20)

From this, we can see that the additional overhead is mainly due to checking intersecting regions. IMO, this is reasonable.