Add sort pause in bags list and trait SortedListProvider

[gpestana]

In the multi-block election context, the snapshot creation takes multiple blocks. As the snapshot is ongoing, all the implicit and explicit rebags/put-in-front-of of the voter and target snapshot should be paused.

Currently and in #6034, the bags list and the SortedListProvider trait does not expose a way to pause moving IDs which is OK to run the election in a single-page context.

Implement the sorted list sorting pause before the multi-page election is rolled out.

---

Goals:

1. Add a new method to trait SortedListProvider to allow locking and unlocking the ordering of the list's elements.
2. Implement a mechanism to lock and unlock the ordering of the list iterator returned by SortedListProvider::iter() implementation of the bags-list.
3. When the lock is set, allow all the bags list mutations that do not change the order of the iterator.

Option 1.

wip implementation at #6510

Return err List::ReorderingNotAllowed whenever a bags-list extrinsic or SortedListProvider method is called that may affect the iterator ordering while the lock is set, ie:

• SortedListProvider::on_insert (inserting ID in the list will change the iter)
• SortedListProvider::on_update (updating an ID score may cause a rebag)
• SortedListProvider::on_remove (removing an ID in the list will change the iter)
• BagsList::call::rebag
• BagsList::call::put_in_front_of
• BagsList::call::put_in_front_of_other

Even tough this approach is simple to implement and can be implemented all at the bags-list level, it may be too strict as some of the sorted list provider method calls may not affect the iter ordering or their implementation could be refactored to apply score mutations without changing the iter ordering e.g. on_update scores without rebag, on_remove do not remove the node from the list, etc.

Option 2.

Same as option 1, but refactor the sorted list provider implementation to ensure that all list mutations happen but ensure the list ordering does not change if the lock is set.

The explicit re-ordering implemented by the bags lists should fail if the lock is set.

• BagsList::call::rebag
• BagsList::call::put_in_front_of
• BagsList::call::put_in_front_of_other

The implicit re-ordering implemented by the sorted list provider should mutate much as possible without changing the iterator ordering:

• SortedListProvider::on_insert: inserts a new ID but at the end of the list.
• SortedListProvider::on_update: updates the ID score but do not rebag/put_in_front_of
• SortedListProvider::on_remove: sets the ID score to zero/taint it but keep it in the list