primary changed twice when pdms rolling update about pd HOT 2 OPEN

/type bug
/severity major
/assign HuSharp

from pd.

For tiup

1. When we have 3 pdms, pdms-0/pdms-1/pdms-2, and pdms-2 is primary
2. upgrade pdms-2 firstly maybe transfer primary to pdms-0
3. uprade pdms-0 will transfer primary again

We can upgrade pdms primary in last place(named defer feature) can avoid unnecessary primary transfer

Ref pingcap/tiup#2414

For operator

tidb-operator does not have the ability to defer feature, it can only upgrade the pods in order.

Furthermore, Thinking about this situation:

1. When we have 3 pdms, pdms-0/pdms-1/pdms-2, and pdms-2 is primary
2. upgrade pdms-2 firstly maybe transfer primary to pdms-1
3. upgrade pdms-1 maybe transfer primary to pdms-0.

To fix it, Assume that current primary ordinal is x, and range is [0, n]

1. Find the max suitable ordinal in (x, n], because they have been upgraded
2. If no suitable ordinal, find the min suitable ordinal in [0, x) to reduce the count of transfer

Ref pingcap/tidb-operator#5643

from pd.