Add integrity test for MaxHolds and MaxFreezes

[pgherveou]

pallet_balances::MaxHolds and pallet_balances::MaxFreezes types defined in the runtime should match the number of enums members in RuntimeHoldReason and RuntimeFreezeReason.

It's a common mistake now to leave these values to () which would prevent any successful balance hold / freeze operations.

We can probably insert some const generic assert to validate it.

[liamaharon]

Would it be better to have these behind the scenes at compile time so the dev doesn't need to worry about them?

[pgherveou]

Sure that's another option, if that's possible we could have the RuntimeHoldReason implement a trait like

trait HoldReasons {
    const MAX_HOLD: usize;
}

and use MAX_HOLD for the Holds boundedVec, getting rid entirely of the MaxHold type.

[Ank4n]

Thinking out loud: having MaxHold as number of variants in RuntimeHoldReason might be an overkill. Not every account will have a hold for every hold reason out there.

I did a query to check what is max locks we have currently in Polkadot. 1 account has 5 locks, 171 has 4 locks, and 238 has 3 locks. So if we set 16 (or may be even 8), we should be fine.

This is the query i used:
// find the max locks
console.log((await api.query.balances.locks.entries()).map(([_, l]) => l.length).reduce((max, current) => max > current ? max : current, 0));

// count for given number of locks
console.log((await api.query.balances.locks.entries()).map(([_, l]) => l.length).filter((x) => x == 5).length);

[ggwpez]

I dont think we can (or need to) do it at compile time. Having it in the integrity_test is fine and quite easy to implement from our side.
Many things are checked there already, so when a parachain dev does not run it then yea 🤷‍♂️