Reduce the conflict when multiple scheduling is running

[nolouch]

Background

Scenario 1: Due to the drop table operation, a large number of merge operations are continuously occurring, and the balance-leader is restricted by the leader-schedule-limit, resulting in the conflict.

Scenario 2: store limit is shared by multiple schedulers.

details

	Store Limit - Add Peer	Store Limit -Remove Peer	leader-schedule-limit	hot-region-schedule-limit	merge-schedule-limit	region-schedule-limit	replica-schedule-limit
BalanceLeader	×	×	√	×	×	×	×
BalanceRegion	√	√	×	×	×	√	×
EvictLeader	×	×	√	×	×	×	×
HotRegion	√	√	√	√	×	√	×
Label
ScatterRange	√	√	√	×	×	√	×
learnerChecker	×	×	×	×	×	×	×
replicaChecker	√	√	×	×	×	√	√
ruleChecker	√	√	×	×	×	√	√
mergeChecker	√	√	√	×	√	√	×

• [ ] Consider do not influence with each other, such as hot-region.
• [ ] Improve the shared behavior for the store limit, such as allow preemption with priority.

[rleungx]

Also some existed problems can be found in https://github.com/tikv/pd/issues/3807

[bufferflies]

Also some existed problems can be found in #3749

[bufferflies]

there are two way to solved the problem that schedulers influenced each other: one way: one operator enter to operator control should only have one OpKind even if the region has many OpKind, the priority is blow(order by the operator cost):

OpMerge >OpHotRegion> OpRange>OpSplit>OpReplica>OpRegion>OpLeader

the other way: modify the scheduler/checker isAllowed condition by subtracting the other OpKind Operators, such as:

balance region scheduler: count(OpRegion)-count(OpMerge)-count(OpHotRegion)<region scheduler limit

leader region scheduler: count(OpLeader)-count(OpMerge)-count(OpHotRegion)<leader scheduler limit

[bufferflies]

the relation between OpKind with scheduler(checker) is blow In past:

[bufferflies]

Let remove-extras-peer not limit #3865

[lhy1024]

@bufferflies Can we close it?