Staking ledger bonding fixes

[gpestana]

Currently, the staking logic does not prevent a controller from becoming a stash of another ledger (introduced by removing this check). Given that the remaining of the code expects that never happens, bonding a ledger with a stash that is a controller of another ledger may lead to data inconsistencies and data losses in bonded ledgers. For more detailed explanation of this issue: https://hackmd.io/@gpestana/HJoBm2tqo/%2FTPdi28H7Qc2mNUqLSMn15w

In a nutshell, when fetching a ledger with a given controller, we may be end up getting the wrong ledger which can lead to unexpected ledger states.

This PR also ensures that set_controller does not lead to data inconsistencies in the staking ledger and bonded storage in the case when a controller of a stash is a stash of another ledger. and improves the staking try-runtime checks to catch potential issues with the storage preemptively.

In summary, there are two important cases here:

1. "Sane" double bonded ledger

When a controller of a ledger is a stash of another ledger. In this case, we have:

> Bonded(stash, controller)
(A, B)  // stash A with controller B
(B, C) // B is also a stash of another ledger
(C, D)

> Ledger(controller)
Ledger(B) = L_a (stash = A)
Ledger(C) = L_b (stash = B)
Ledger(D) = L_c (stash = C)

In this case, the ledgers can be mutated and all operations are OK. However, we should not allow set_controller to be called if it means it results in a "corrupt" double bonded ledger (see below).

3. "Corrupt" double bonded ledger

> Bonded(stash, controller)
(A, B)  // stash A with controller B
(B, B)
(C, D)

In this case, B is a stash and controller AND is corrupted, since B is responsible for 2 ledgers which is not correct and will lead to inconsistent states. Thus, in this case, in this PR we are preventing these ledgers from mutating (i.e. operations like bonding extra etc) until the ledger is brought back to a consistent state.

---

Changes:

• Checks if stash is already a controller when calling Call::bond (fixes the regression introduced by removing this check);
• Ensures that all fetching ledgers from storage are done through the StakingLedger API;
• Ensures that -- when fetching a ledger from storage using the StakingLedger API --, a Error::BadState is returned if the ledger bonding is in a bad state. This prevents bad ledgers from mutating (e.g. bond_extra, set_controller, etc) its state and avoid further data inconsistencies.
• Prevents stashes which are controllers or another ledger from calling set_controller, since that may lead to a bad state.
• Adds further try-state runtime checks that check if there are ledgers in a bad state based on their bonded metadata.

Related to #3245

[Ank4n]

Pretty important fix 🙏 .

The whole stash/controller logic is not so great. Intuitively I would have not expected Ledger to be keyed by controller which seems the core issue behind this bug. Another observation is, it is not very clear why some extrinsics in staking pallet can be called via stash and others via controller.

[EgorPopelyaev]

@gpestana just for info: prdoc file is missing here, which is needed to pass the CI check and also if you want this pr to be mentioned in the release notes

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-digest-19-mar-2024/6889/1

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/parity-tech-update-for-march/7226/1