cherry-pick #7672 to release-3.1

Signed-off-by: Liqi Geng gengliqiii@gmail.com

What problem does this PR solve?

Problem Summary:

In the past, we assume some target peers may not exist during merging. It introduces many complexities that we need to think about how to handle it.

Also, there are some cases we can not handle.

For example, a target peer does not exist during merging. Its corresponding source peer is waiting for it to be created. Then other target peers do the conf change and remove it(though it never existed). Next, the target region merges to another target region.

In this case, the waiting source peer can not find out whether it should be removed. (It's very difficult, the PD knows nothing because the target region has merged to another one)

Luckily, in tikv/pd#839 (the earliest PR about merging in PD), it checks the target peer's pending peer count must equal to zero.
So we can rely on the all-target-peer-exist guarantee to make it easier and save our brain power.

What is changed and how it works?

What's Changed:

Rely on the all-target-peer-exist guarantee during merging.
Remove some code about handling some cases when a target peer may not exist during merging.

Related changes

• Need to cherry-pick to the release branch

Check List

Tests

• No code

Side effects

We should check it twice whether the earliest version can give us this guarantee.
Otherwise, it will break backward compatibility.

Release note

• Fix a case that a peer can not be removed when its store is isolated during multiple merge process.