Add extrinsic to improve position in a bag of bags-list

[emostov]

This PR adds the extrinsic put_in_front_of which allows the user to specify a lighter and heavier account within the same bag and the extrinsic will move heavier directly in front of lighter. The parameter names refer to the fact that lighter must have a lower VoteWeight then heavier.

In the ideal use case, where a user wants to improve the position of their account within a bag, the user would iterate the bag, starting from the head, and find the first node who's VoteWeight is less than theirs. They would then supply the id of the node as the lighter argument and their own id as the heavier argument.

polkadot companion: paritytech/polkadot#3899

---

Below is a table with some combinations of edge case and the name of the relevant unit test

	heavier head	heavier tail	heavier non-terminal (in front)	heavier non-terminal (behind)
lighter head	NA	put_in_front_of_heavier_is_tail_lighter_is_head	NA	put_in_front_of_lighter_is_head_heavier_is_non_terminal
lighter tail	put_in_front_of_lighter_is_tail_heavier_is_head	NA	NA	put_in_front_of_lighter_is_tail_heavier_is_not_terminal
lighter non-terminal (in front)	NA	put_in_front_of_heavier_is_tail_lighter_is_non_terminal	NA	put_in_front_of_non_terminal_nodes_heavier_behind
lighter non-terminal (behind)	put_in_front_of_heavier_is_head_lighter_is_not_terminal	NA	put_in_front_of_non_terminal_nodes_heavier_in_front	NA

TODO

• if this is permissioned, investigate a reasonable way for allowing the stash to call this - perhaps either via proxy or the controller.

skip check-dependent-cumulus

[emostov]

/benchmark runtime pallet pallet_bags_list

[kianenigma]

Here you are assuming that the lighter node could only ever be a head, and the heavier node could only ever be a tail, while I don't see that being guaranteed. Can you elaborate all the edge cases that you considered, and why you think this is enough?

[kianenigma]

here's an idea to break this down into smaller bite-size pieces:

1. For removing, we simply use the current fn remove(). After all the checks, we immediately remove heavier. The logic for this function should already update the Bag head/tail if heavier.is_terminal().
2. For inserting, we write a private helper function as such:

fn insert_at(after: Option<Node>) {
	if let Some(x) = after {
		// new logic, insert a new node on the prev of `after`  
	} else {
		// insert at tail: delegate to whatever we do now
	}
}

This will require the least amount of added logic, which helps with verifying the correctness of the PR (assuming that none of the old code was buggy).

---

If we keep the current code, here's a mental model to check it

1. none are terminal
2. lighter is head, heavier is not terminal (common case)
3. lighter is tail, heavier is not terminal (mistake case)
4. heavier is tail, lighter is not terminal (common case)
5. heavier is head, lighter is not terminal (mistake case)
6. lighter is head, heavier is tail (common case)
7. lighter is tail, heavier is head (mistake case)

and for any case that contains a non-terminal, we have to consider if they are adjacent or not (in case 5 it totally makes a different).

I'm going to now start thinking about each case and how it is handled.

[kianenigma]

My analysis shows case 5 is not handled correctly, when the non-terminal lighter is not adjacent to the heavier one.

#[test]
fn heavier_is_head_lighter_is_not_terminal() {
	ExtBuilder::default().add_ids(vec![(5, 1000)]).build_and_execute(|| {
		// given
		assert_eq!(List::<Runtime>::get_bags(), vec![(10, vec![1]), (1_000, vec![2, 3, 4, 5])]);
		// when
		BagsList::put_in_front_of(Origin::signed(0), 2, 4).unwrap();
		// then.. :(
		assert_eq!(List::<Runtime>::get_bags(), vec![(10, vec![1]), (1_000, vec![3, 2, 4, 5])]);
	});
}

I'd like to see the fix, but my gut feeling is that rewriting it using smaller functions is easier. This if conditions_in_which_we_might_update_bags {} is a bit hard to verify. If we first remove, then update everything, and then insert, and update everything again, there would probably be a few extra (IMO negligible) lookups to the overlay, but the (non-negligible) db access would be the same.

[emostov]

fa1a33d

[kianenigma]

Might have some unconsidered edge cases here. https://github.com/paritytech/substrate/pull/9829/files#r714053661

[emostov]

Might have some unconsidered edge cases here. https://github.com/paritytech/substrate/pull/9829/files#r714053661

yup, definitely missed some. To try and be thorough I created this table for edge cases and filled it with the names of relevant unit tests

	heavier head	heavier tail	heavier non-terminal (in front)	heavier non-terminal (behind)
lighter head	NA	put_in_front_of_heavier_is_tail_lighter_is_head	NA	put_in_front_of_lighter_is_head_heavier_is_non_terminal
lighter tail	put_in_front_of_lighter_is_tail_heavier_is_head	NA	NA	put_in_front_of_lighter_is_tail_heavier_is_not_terminal
lighter non-terminal (in front)	NA	put_in_front_of_heavier_is_tail_lighter_is_non_terminal	NA	put_in_front_of_non_terminal_nodes_heavier_behind
lighter non-terminal (behind)	put_in_front_of_heavier_is_head_lighter_is_not_terminal	NA	put_in_front_of_non_terminal_nodes_heavier_in_front	NA

[thiolliere]

looks good to me, minor grumble above, but they should better be addressed IMO.
Also #9829 (comment)

[thiolliere]

all good to me, we can merge

[emostov]

bot merge

[paritytech-processbot]

Error: It's not possible to meet the minimal approval count of 1 in paritytech/polkadot#3899

[emostov]

bot merge

[paritytech-processbot]

Error: It's not possible to meet the minimal approval count of 1 in paritytech/polkadot#3899

[emostov]

Error: It's not possible to meet the minimal approval count of 1 in paritytech/polkadot#3899

Not sure whats up here, @thiolliere already approved the companion

[shawntabrizi]

bot merge