fix: rolling update current leader handling

[thweetkomputer]

What changed

• Removed the eloqctl update --current-master-nodes option; rolling update now discovers current topology from CLUSTER NODES.
• Extended topology parsing to keep Redis node ids, replica master_id, and voter nodes instead of treating all non-replicas as masters.
• Changed standby rolling update sequencing:
  1. Discover connected current masters and their connected replicas.
  2. Fail over each master to its matching standby replica.
  3. Wait until the selected standby is reported as a connected master.
  4. Restart all remaining KV nodes one by one, including voters.
  5. Restart the temporary leader nodes last and let normal election/preferred-leader behavior settle the final leader.
• Kept --skip-log-restart support so standalone log service restart can be skipped during update.

Why

The previous rolling update path depended on configuration order or a manually supplied current master list. That is unsafe when the actual master differs from the configured master, and it does not handle voter restart sequencing clearly.

The new flow uses live CLUSTER NODES state, keeps a temporary standby leader alive while the other nodes are upgraded, and only restarts that temporary leader at the end.

Validation

• cargo check -p cluster_mgr
• cargo build --release -p cluster_mgr --bin eloqctl
• cargo test -p cluster_mgr topology_task_uses_standby_startup_node_when_master_is_down