Rework coldkey swap

[l0r1s]

Closes #2230

Summary

This PR refactors the coldkey swap mechanism from a scheduler-based system to an announcement-based system with a configurable delay period. This change improves security, simplifies the codebase, and provides better transparency for coldkey swap operations.

Key Changes

1. New Announcement-Based Flow

• Added announce_coldkey_swap: Users must first announce their intention to swap coldkeys by providing a hash of the new coldkey
• Added swap_coldkey_announced: After the announcement delay period, users can execute the swap by providing the actual new coldkey
• Announcement validation: The system verifies that the new coldkey hash matches the announced hash and that sufficient time has passed

2. Configuration Changes

• Renamed: InitialColdkeySwapScheduleDuration → InitialColdkeySwapAnnouncementDelay
• Removed: InitialColdkeySwapRescheduleDuration (no longer needed)
• Storage: ColdkeySwapScheduled map → ColdkeySwapAnnouncements map
• Default delay: Maintained at 5 days (36,000 blocks)

3. Refactored Core Swap Logic

• Simplified do_swap_coldkey: Consolidated swap logic with clearer separation of concerns
• New helper functions:
  • transfer_subnet_ownership
  • transfer_auto_stake_destination
  • transfer_coldkey_stake
  • transfer_staking_hotkeys
  • transfer_hotkeys_ownership
• Identity preservation: If new coldkey already has an identity, it's preserved instead of overwritten

4. Updated swap_coldkey Extrinsic

• Now root-only for arbitrary coldkey swaps (doesn't require announcement)
• Automatically removes any existing announcement when called
• Returns DispatchResult instead of DispatchResultWithPostInfo

5. Admin Utilities

• Deprecated: sudo_set_coldkey_swap_schedule_duration (call index 54)
• Added: sudo_set_coldkey_swap_announcement_delay (call index 84)
• Added: remove_coldkey_swap_announcement (call index 127) - root-only removal of announcements

6. Events

• Removed: ColdkeySwapScheduled
• Added:
  • ColdkeySwapAnnounced - emitted when an announcement is made
  • ColdkeySwapAnnouncementRemoved - emitted when an announcement is removed
• Updated: ColdkeySwapAnnouncementDelaySet (renamed from ColdkeySwapScheduleDurationSet)

7. Error Handling

• Removed: ColdkeyIsInArbitration, SwapAlreadyScheduled, FailedToSchedule
• Added:
  • ColdkeySwapAnnouncementNotFound
  • ColdkeySwapTooEarly
  • ColdkeySwapReannouncedTooEarly
  • AnnouncedColdkeyHashDoesNotMatch
  • Deprecated (for the old schedule_swap_coldkey call)

8. Transaction Extension

• Updated CustomTransactionError::ColdkeyInSwapSchedule → ColdkeySwapAnnounced

9. Migration

• Added: migrate_coldkey_swap_scheduled_to_announcements to migrate existing scheduled swaps to the new announcement system
• Only migrates future scheduled swaps (past ones are ignored)
• Adjusts announcement time to be scheduled_time - delay so swaps can execute at the originally scheduled time

Benefits

1. Improved Security: Announcement hash prevents front-running and ensures the exact coldkey is swapped
2. Transparency: All announcements are publicly visible on-chain before execution
3. Simplified Code: Removes complex scheduler integration and reduces storage requirements
4. Flexibility: Users can reannounce after the delay period expires
5. Root Override: Admins can still perform emergency swaps via the root-only swap_coldkey call

Breaking Changes

⚠️ BREAKING CHANGES:

• The schedule_swap_coldkey extrinsic is deprecated and will return an error
• Configuration parameters renamed (migration handled automatically)
• Storage layout changed (migration included)

Migration Path

For users with existing scheduled coldkey swaps:

• The migration will automatically convert scheduled swaps to announcements
• Your swap can still be executed at the originally scheduled time using swap_coldkey_announced
• Ensure you have the new coldkey available when the delay period expires

[shamil-gadelshin]

Looks good! I have a general question about enums and public API preservation.

[shamil-gadelshin]

Shouldn't we deprecate enum items instead of deleting them?

[camfairchild]

imo this is fine because we should expect clients to use the metadata from the chain to handle decoding, etc.

[shamil-gadelshin]

Shouldn't we deprecate enum items instead of deleting them?