[Staking] Make exits manual, patch lack of delay for {increasing, decreasing} bonds

[4meta5]

Changes how exits and bond changes are scheduled, executed, and cancelled. It also changed the terminology from NPoS to DPoS i.e. nominator -> delegator, nomination -> delegation.

Logic changes include:

1. The ExitQueue is replaced by manual exits. This requires more interaction from users to request {exits, bond changes} and execute them after a delay.
2. Adds 2 round delay to bond_{more, less} requests by collator candidates and delegators. The execution is not automatic and requires an execute_ call by any signed account.

Please review the precompiles/parachain-staking/StakingInterface.sol to see the changes to the precompile interface.

Automatic -> Manual Execution

Before execution of delayed exits was automatic, but now an execute extrinsic is added for all exit and bond actions for candidates and delegators.

The execute extrinsics can be called by any signed origin but only executes if there is a pending request and it has waited the 2 round delay (at least 2 rounds after the round in which the request was made).

There is no explicit reward for executing someone else's request, but this design provides some disincentive for queueing up requests without the intention to execute (because anyone else can execute them and some users may have economic incentive to do so i.e. if it increases their relative share of staking rewards).

New Exit Rules

The only constraint is that delegators cannot schedule_leave_delegators and then delegate (assuming not calling cancel_leave_delegators in between). So delegators cannot delegate in a leaving state.

Everything else is allowed during candidate or delegator leaving now because lots of constraints were relaxed.

Relaxed Constraints

When the candidate is scheduled to leave,

1. the candidate can requests to bond_{more, less} and can execute pending requests.
2. delegators can make requests to {revoke, bond_{more, less}} and can execute these requests.
3. delegators can make request to leave (revoke all delegations) and can execute the exit request.
4. delegators can make new delegations to the candidate.

The candidate can make at most 1 request to adjust their self bond (bond_{more, less}). If a second request is made, it returns an error and the storage state before the call is preserved.

When the delegator is scheduled to leave, the delegator can make requests to {revoke, bond_{more, less}} and execute pending requests.

The delegator can make at most 1 pending request to {revoke, bond_{more, less}} per delegation. When the delegator is making a pending request to {revoke, bond_{more, less}} for a specific candidate, the delegator cannot make any additional requests to change the given delegation (unless they cancel the first request).

Follow Up Tasks

• remove deprecated storage item code (ExitQueue, CollatorState2, NominatorState2)
• add back TS tests for bond and exits (is there run_to_block in TS?)

[notlesh]

This could be pretty heavy CPU-wise, I wonder if your 10% estimate might be insufficient here...

[4meta5]

This method is a custom From conversion from struct Nominator2 to struct Delegator which also takes 1 parameter. So I don't think the conversion itself is expensive.

I'm more worried about iterating all the items in the NominatorState2 map, maybe that's what you were referring to?

Either way, we can increase the margin of safety.

[4meta5]

increased to 50%

[notlesh]

Yeah, it looks like we can expect around 3k of them. I think we'll be ok, but (as I mentioned privately) I'll help you test this with try-runtime.

[notlesh]

This is maybe more of a note to myself to verify later, but does this OrderedSet need to be re-sorted upon migration?

[notlesh]

Nevermind, I don't think this question makes sense, but I still want to revisit it

[4meta5]

No need to resort. I expect the order to be preserved, but maybe worth verifying.

Moreover, the ordering isn't actually used anywhere, the OrderedSet is used to enforce the set constraint that there can be no two delegations to the same candidate. A better data structure could be used, definitely, but not in scope for this PR.

It'd be great to remove OrderedSet altogether, but it would require migrating a few storage items.

[notlesh]

should we be reserving here instead of waiting?

[4meta5]

No because this is scheduling the increase, not executing it. We could remove this check altogether, but I think we shouldn't allow someone to schedule the request without having the liquid balance to execute it. They could transfer the balance out in between, but the reserve in the execution logic would still require they transfer it back in before executing.

[notlesh]

(if not, a test case to cover issues like "scheduled to bond more and then spent those funds before executing" could be useful)

[4meta5]

Any further review can still be addressed in follow ups!