Problem

With Permissionless ICS, we can permissionlessly introduce new consumer chains. However, those consumer chains might send ICS rewards over to the provider chain in a denom that is not white listed. The only way to currently white list a denom is through a gov proposal which (slightly) defeats the purpose of permissionless.

Idea for a solution

• The idea here is to allow each consumer chain to permissionlessly introduce at most 3 allowlisted denoms. This can be done by modifying the MsgChangeRewardDenoms message.
• When rewards are sent to the provider (in ibc_middleware.go) those would be stored under a key = consumerId | denom => rewards association. This state could contain multiple denoms, even ones that are not whitelisted.
• When we distribute rewards for a consumer with consumerId, we only go through all the current governance-allowlisted denoms, as well as all the denoms allowlisted by this specific consumer chain. For all those denoms, we check if there are any rewards under key = consumerId | denom and if so, those rewards are distributed accordingly to validators.

Note that the consumer chain does not have to be necessarily launched for it to registere at most 3 allowlisted denoms. That's because we only distribute rewards to launched validators.