[Features] Support scaling out before scaling in for a specific shard or component

[starnop]

What is the user interaction of your feature
A concise description of user interactions or user stories of your feature request

In the actual production environment, for example, when replacing an instance, to ensure service stability, we usually want to scale out a new instance first and then scale in an old one.

At present, for components, we can manually divide them into two steps, the first step is to perform the scale out opsrequest, and the second step is to perform the scale in opsrequest, to achieve the above goal.

However, for sharding API, it is temporarily impossible if you want to implement the scale-out first and then scale in an instance under a specified shard because we can't increase the number of cases by 1 and then decrease it by 1 for a particular shard.

In my opinion, there are two possible solutions here:

1. Supports heterogeneous capabilities in the sharding dimension and supports configurations such as different replicas for each shard
2. Similar to maxsurge, it allows scaling out first and then scaling in while maintaining the same replica configuration.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

If this is a new feature, please describe the motivation and goals.
A clear and concise description of why you want to happen, link the design doc if possible

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[shanshanying]

Hi @starnop ,

In my understanding, stateful applications (e.g., databases, distributed systems) requires stable, unique network identifiers. But the maxSurge field will break the constraint, and works better for state-less apllication (deployment).

Maybe we can provide a way to controlle replicas for each shard as a solution.