feat: support deferred mode for alter parallelism

[shanicky]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

When using the DEFERRED parameter with commands like ALTER TABLE, it only modifies the parallelism field in the meta information of the streaming job and doesn't perform an actual scaling. The modification is left to be handled by the subsequent auto scale loop.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• All checks passed in ./risedev check (or alias, ./risedev c)

[BugenZhao]

Could you please elaborate more on the motivation?

[shanicky]

Could you please elaborate more on the motivation?

Normally, an ALTER statement requires the scaling to succeed before updating the parallelism of the streaming job. However, in some cases, this might not be suitable. For instance, if there's a desire to forcefully change a custom job to automatic, or in emergency situations, such as when the current cluster's parallelism is insufficient for fixed requirements, you might need to forcefully reduce the degree of parallelism. 'deferred' is a parameter thought up by AI, signifying a delayed scaling.

[yezizp2012]

I think it is acceptable to keep such a quick path to modify the streaming job parallelism, but it is better not to have any public documents. It should only be used in urgent situations when the user cluster load is too high and the response time is not timely. Because this can easily cause inconsistencies, after supporting trigger recovery manually we'd better call it here rather than rebooting the meta.