Find Elegant Solution if Fee Escrow account is out of balance

[AdityaSripal]

The current way to deal with the worst-case scenario of when escrow account is out of balance is to disable the fee module on all channels.

However, this will only happen on our channel end. The other channel end will continue with the fee module enabled since there isn't a good way to communicate that our side has disabled fees once the channel is already open.

This will lead to an invalid state where one side has fee enabled and the other side does not.

We should determine a better way to handle this case.

Perhaps we keep fee enabled, but just do not distribute the fee on our side.

Thanks to @soareschen for pointing this out

[colin-axner]

Should we close the channel? That would allow the counterparty to close as well

I guess maybe we would assume in this case we want to pause the channel until a fix is hard forked in?

It is interesting to think about how a middleware could close a channel (overriding the connected base application)

[colin-axner]

After some discussion:

• receiving side continues function as normal since it does not use an escrow account
• sending side disables incentivizing new packets and does not distribute from the escrow account

[colin-axner]

I'm working on this in smaller pieces, but in general:

• when escrow balance will be negative -> disable all channels
• when writing an acknowledgement, if the channel is disabled + the fee version is set -> return ics29 ack

[colin-axner]

After some more thought, the existence of insufficient balance of the escrow account doesn't need to disable all channels (whether it occurs on channel closure or fee distribution). Part of these channels will be on the receiving side and thus have no interaction with the escrow module

I'll add a single mapping to a boolean in the keeper which will indicate if the fee escrow module is locked (due to insufficient balance)