x/participationrewards/keeper: Keeper.AfterEpochEnd has potential non-determinism from running k.prSubmodules.each.Hook from a map, if the order of the hooks matters

[odeke-em]

Summary of Bug

If we examine this code

quicksilver/x/participationrewards/keeper/hooks.go

Lines 67 to 69 in 02bd08d

	for _, sub := range k.prSubmodules {
	sub.Hooks(ctx, k)
	}

we can infer from the definition

quicksilver/x/participationrewards/keeper/keeper.go

Line 56 in 02bd08d

prSubmodules map[cmtypes.ClaimType]Submodule

that for the various claim types we have different submodules and run a hook.

The question is does it matter which the order that those hooks run? If so, we've got non-determinism here and that cause subtle behavior and in much more serious cases chain halts

Expected Behaviour

The simplest way to fix this would be to invoke claimTypes := maps.Keys(k.prSubmodules) + slice.Sort(claimTypes) and then using those sorted keys to iterate and infer the hook from the map; that'll maintain a deterministic sorted order for iterating over and applying those the exact same way for every single node/validator

/cc @faddat @joe-bowman

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned