rollback or checkpoint resume if dm scale-out failed

Feature Request

Is your feature request related to a problem? Please describe:

I'm scale-out dm with two more nodes, failed of reload prometheus before the end, and I'm manually starting promethes/grafana , and want to run scale-out again, but the checking failed:

the Prometheus reload failed

Error: stdout: , stderr:prometheus-9090.service is not active, cannot reload.
: executor.ssh.execute_failed: Failed to execute command over SSH for 'tidb@172.19.0.101:22' {ssh_stderr: prometheus-9090.service is not active, cannot reload.
, ssh_stdout: , ssh_command: export LANG=C; PATH=$PATH:/usr/bin:/usr/sbin sudo -H bash -c "systemctl daemon-reload && systemctl reload prometheus-9090.service"}, cause: Process exited with status 1

Verbose debug logs has been written to /root/.tiup/logs/tiup-dm-debug-2021-01-30-15-42-54.log.

Rerun the scale-out command

root@control:/tiup-cluster# tiup-dm scale-out dm scale_dm.yaml

Error: port conflict for '8261' between 'master_servers:172.19.0.105.port,omitempty' and 'master_servers:172.19.0.105.port,omitempty'

Describe the feature you'd like:

• don't save the topology if scale-out not success;
• or rollback the topology if scale-out failed;
• or resume the previous scale-out process;

I prefer the first one.

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Start with the reported tiup-dm scale-out dm scale_dm.yaml flow and the debug log from the failed Prometheus reload. Compare the topology state after a failed scale-out with the state expected for a retry; done should be defined as preventing an invalid saved topology, rolling back safely, or resuming the interrupted operation.