feat: batch region migration for failover

[WenyXu]

I hereby agree to the terms of the GreptimeDB CLA.

Refer to a related PR or issue link (optional)

#7021

What's changed and what's your intention?

Previously, when multiple regions from the same datanode needed to be migrated to another datanode during failover, each region was processed individually in separate migration procedures. This PR refactors the failover logic to batch regions by their source and destination peers, allowing multiple regions to be migrated together in a single procedure.

Changes

1. Event Recorder Refactoring

• Refactor event recorder to support multiple rows per event: Modified the event recording infrastructure to support recording multiple rows for a single event, which enables better tracking of batch operations.
• Updated EventRecorder interface and implementation
• Modified region migration event recording to leverage the new batch capability

2. Batch Region Migration Support

• Group failover tasks by peer pairs: Refactored RegionSupervisor::do_failover() to group migration tasks by (from_peer_id, to_peer_id) pairs before submission
• New batch submission API: Added RegionMigrationManager::submit_region_migration_task() to handle batch region migration requests
• Comprehensive result handling: Introduced SubmitRegionMigrationTaskResult to track different migration outcomes:
  • migrated: Regions already at the target peer
  • migrating: Regions with ongoing migrations
  • table_not_found: Regions whose tables have been dropped
  • leader_changed: Regions where leadership has changed
  • peer_conflict: Regions with peer conflicts
  • submitted: Regions successfully submitted for migration
• New utility module: Added utils.rs with RegionMigrationTask and analysis functions to support batch operations
• Improved logging: Enhanced logging to show batch operation details with region lists

PR Checklist

Please convert it to a draft if some of the following conditions are not met.

• I have written the necessary rustdoc comments.
• I have added the necessary unit tests and integration tests.
• This PR requires documentation updates.
• API changes are backward compatible.
• Schema or data changes are backward compatible.