Voluntary deregistration

[ppolewicz]

Description

This PR introduces the entire voluntary-deregistration feature set for subnets. We now track subnets that wish to be pruned via a dedicated SubnetDeregistrationPriorityQueue, before using the old immunity/price pruning flow. Subnet owners (or root) can call schedule_deregistration_priority, which creates a timed entry using a configurable DeregistrationPriorityScheduleDelay. Once the (~5 day) delay elapses, the scheduler enqueues the subnet for deregistration, firing SubnetDeregistrationPriorityQueueAdded event, and from this point get_network_to_prune will prefer these queued subnets over price-based candidates—even during immunity.

A new helper module encapsulates the lifecycle: scheduling, enqueueing, canceling, clearing, and forcing entries—while the public extrinsics (schedule_deregistration_priority, cancel_deregistration_priority_schedules, enqueue_subnet_deregistration, clear_deregistration_priority) simply perform origin checks and delegate. Dissolution automatically removes any queue/schedule remnants so newly registered subnets never inherit stale priority. Root can adjust the delay via the new sudo_set_deregistration_priority_schedule_delay and all runtimes/mocks/benchmarks now provide and exercise this constant.

Events were implemented (SubnetDeregistrationPriorityScheduleAdded/Removed, …QueueAdded/Removed, DeregistrationPriorityScheduleDelaySet) to reflect the queue-centric design, and there is a new cradle-to-grave test (schedule_priority_full_lifecycle_to_dissolution) that schedules a subnet for deregistration, simulates the scheduler firing, confirms pruning behavior and dissolves the subnet while asserting each event fires at the right time.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[JohnReedV]

Looks good. Need to fix CI

[xerion12]

now this is following good design patterns and clear separation between scheduling and queue logic, which helps keep code organized and easy to follow. Integration with coldkey swap is smart, preventing conflicts when owners schedule both actions, and access control is well thought, allowing subnet owners to schedule or cancel but not remove from queue, while root keeps full control. Defensive programming is used, like checking subnet existence and preventing duplicates, but the queue uses Vec with O(n2) removal, so performance could be better if VecDeque is used instead for O(1) operations. There is no max size limit for the queue, which might be risky if someone tries to fill it, and scheduler slots are consumed with each schedule, so rate limiting could be considered. Error handling is a bit inconsistent, some functions return bool while others use Result, and force_set_deregistration_priority could check subnet existence before enqueueing. Documentation is not very clear about the 5day delay and queue order, and some storage items need more comments. Overall, it’s a strong feature with solid architecture and testing, but needs fixes in performance, security, and documentation before merge. One unique idea is to add a warning event when the queue is near full, so admins can monitor for potential abuse, and maybe allow configurable delay for different subnets.

[antlerminator]

Suggested change

	if let Some(priority_netuid) = Self::pop_ready_subnet_deregistration_priority(current_block)
	if let Some(priority_netuid) = Self::pop_ready_subnet_deregistration_priority()

Unnecessary passed arg

[antlerminator]

Why? 👀

[ppolewicz]

some code formatter did it I guess. I'll try to remove

[antlerminator]

Suggested change

	SubnetDeregistrationPriorityScheduled(NetUid, BlockNumberFor<T>),
	SubnetDeregistrationPriorityScheduled(NetUid, BlockNumberForEnqueueing<T>),

I'd be more explicit on the arg name as you cannot quickly infer from the context what this block number is for exactly.

[ppolewicz]

That's a type, not an argument name

[shamil-gadelshin]

A couple of comments (cc @ppolewicz):

• consider refactoring manage_deregistration_priority into several extrinsics
• add events and block progress (test scheduling) to tests - we have infrastructure for this
• John has removed an indexing issue we discussed offline
• consider adding several e2e scenarios from the first scheduling up to network dissolution
• please, verify the issue we discussed within force_set_deregistration_priority

Splitting the main extrinsic should simplify the workflow and make the code and test review simpler.

[ppolewicz]

I fixed most stuff, but I'm still working on it