feat(cluster): expose slot migration progress in CLUSTER INFO

[git-hulk]

What does this PR do?

Currently, while a slot migration is running, CLUSTER INFO only reports migrating_slot(s), destination_node, and migrating_state: start. All progress details (key counters, sent bytes/batches, WAL catch-up) exist internally but are only written to server logs at the end of each phase, so operators have no way to observe an in-flight migration or estimate how far along it is.

This PR exposes the detailed progress of the ongoing migration task via CLUSTER INFO while the migration state is start:

migrating_slot(s): 1
destination_node: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx01
migrating_state: start
migrating_stage: snapshot
migrating_elapsed_ms: 1202
migrating_keys_migrated: 0
migrating_keys_expired: 0
migrating_keys_empty: 0
migrating_sent_bytes: 1257196
migrating_sent_batches: 74
migrating_sent_entries: 3568
migrating_rate_kbps: 1021.98
migrating_wal_sequence_gap: 12

• migrating_stage: the current stage of the state machine (start/snapshot/wal/success/failed/clean).
• migrating_keys_*: snapshot key counters, only counted by the redis-command migration type.
• migrating_sent_bytes/batches/entries: data sent to the destination node. For the redis-command type, a batch is a pipeline of commands and an entry is a command; for the raw-key-value type, a batch is an APPLYBATCH write batch and an entry is a write batch operation.
• migrating_wal_sequence_gap: the distance between the latest sequence number and the WAL sequence the migration has caught up to, i.e. the pending incremental data.

The existing fields are unchanged, and the new fields are only emitted while the task is ongoing, so existing tools polling migrating_state are unaffected. All counters are emitted in both migration types (zeros where a type doesn't use them) so that parsers don't need to be aware of the migrate-type config.

This also makes current_stage_ and wal_begin_seq_ atomic since they are now read from other threads while the migration thread updates them (current_stage_ was already read cross-thread by Server::WaitNoMigrateProcessing).

Testing

Added two integration tests that hold a migration in flight (via migrate-speed / migrate-batch-rate-limit-mb) and verify the progress counters go non-zero during the migration for both migration types, and that the fields disappear after the task finishes.

🤖 Generated with Claude Code

[git-hulk]

I haven't reviewed this PR yet, will reopen after that.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud