Fix wrong allowed_currencies_len variable

[ebma]

Changes the allowed_currencies_len to use the length of the updated AllowedCurrencies for the second size check (instead of doing a redundant check on the passed currencies vector).

Also adds a similar check to the remove_allowed_currencies extrinsic. While in theory, it would of course never be possible to remove more currencies than are contained in the AllowedCurrencies storage item, which is limited to the MaxAllowedCurrencies config parameter in our add_allowed_currencies function, the caller could still provide a very large and valid currencies vector to this function and thus bloat the chain. That's why also checking the max size of the vector makes sense here.

Closes #297.

[adelarja]

Looks good to me!

[TorstenStueber]

Why are the weight definitions of these two extrinsics add_allowed_currencies(T::MaxAllowedCurrencies::get()) and remove_allowed_currencies(T::MaxAllowedCurrencies::get()) instead of taking the actual length of the currencies argument into account, i.e.:

• add_allowed_currencies(currencies.len() as u32) and
• remove_allowed_currencies(currencies.len() as u32)

This is what I originally referred to in this comment.

I think that would eliminate all problems.

[ebma]

@TorstenStueber as you can see in the code that you link to in your other comment, when defining the weight in the [pallet::weight] macro, they also use the config variable that represents the maximum possible value. If you then look at the actual definition of the set_sub_olds weight function declaration here, it's declared using a range variable. This is exactly how we also do it, defining the maximum possible value here but using a range variable in the weight function here.

[TorstenStueber]

This difference is of course that they also add T::WeightInfo::set_subs_new(subs.len() as u32). But that's really a nitpick. Your solution is fine.