[Enhancement] auto change replication_num of system tables (backport #51799)

[murphyatwork]

Why I'm doing:

When scale-in the cluster from 3 nodes to 1 node:

• Since the system tables in _statistics_ database will have 3 replicas, they would stop the scale-in
• The current solution is to drop this database and recreate it, but which is not safe actually

What I'm doing:

Auto change replication_num of several system tables

• When scaling out to more than 3 nodes, change the replication_num to 3
• When scaling in to 1 node, change the replication_num to 1, otherwise scale-in would never succeed

Affected system tables:

• column_statistics
• histogram_statistics
• table_statistic_v1
• external_column_statistics
• external_histogram_statistics
• 3.2: pipe_file_list
• 3.3: loads_history
• 3.3: task_run_history

Behavior change:

• before: the replication_num will only be increased but not decreased
• now: the replication_num will be increased when scale-out, and decreased when scale-in

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 3.3
  • 3.2
  • 3.1
  • 3.0
  • 2.5

---

This is an automatic backport of pull request #51799 done by [Mergify](https://mergify.com). ## Why I'm doing:

When scale-in the cluster from 3 nodes to 1 node:

• Since the system tables in _statistics_ database will have 3 replicas, they would stop the scale-in
• The current solution is to drop this database and recreate it, but which is not safe actually

What I'm doing:

Auto change replication_num of several system tables

• When scaling out to more than 3 nodes, change the replication_num to 3
• When scaling in to 1 node, change the replication_num to 1, otherwise scale-in would never succeed

Affected system tables:

• column_statistics
• histogram_statistics
• table_statistic_v1
• external_column_statistics
• external_histogram_statistics
• 3.2: pipe_file_list
• 3.3: loads_history
• 3.3: task_run_history

Behavior change:

• before: the replication_num will only be increased but not decreased
• now: the replication_num will be increased when scale-out, and decreased when scale-in

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

Why I'm doing:

When scale-in the cluster from 3 nodes to 1 node:

• Since the system tables in _statistics_ database will have 3 replicas, they would stop the scale-in
• The current solution is to drop this database and recreate it, but which is not safe actually

What I'm doing:

Auto change replication_num of several system tables

• When scaling out to more than 3 nodes, change the replication_num to 3
• When scaling in to 1 node, change the replication_num to 1, otherwise scale-in would never succeed

Affected system tables:

• column_statistics
• histogram_statistics
• table_statistic_v1
• external_column_statistics
• external_histogram_statistics
• 3.2: pipe_file_list
• 3.3: loads_history
• 3.3: task_run_history

Behavior change:

• before: the replication_num will only be increased but not decreased
• now: the replication_num will be increased when scale-out, and decreased when scale-in

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud