Failing a transaction with a profile results in never-ending balance withdraws

[RiccardoM]

Bug description

Inside Apollo, if you perform a transaction with a fee after you create a profile, and that transaction fails, your balance will start loosing tokens every block until there are no more funds to get.

Steps to reproduce

1. Create a new account
2. Send that account some tokens
3. Create a profile for that account
4. Perform a failing transaction with that account (eg. a send with amount greater than the overall balance) and set a fee
5. Watch the balance continuously dropping

Expected behavior

After a transaction fails, the balance should not continue to drop.

[RiccardoM]

After a lot of investigations, and thanks to @dimiandre and @AmauryM, we found out what was causing this.

Apparently, inside Cosmos when a transaction fails the sequence of the account is incremented anyway. This results, on the next block, to make the transaction invalid as the account will have a different sequence from the one used to sign it. Being invalid, the transaction will be removed from the mempool and not be included in the next block.

In this case, when a transaction is performed by a Profile-owning account, if it's invalid it is not removed from the mempool. This results in it being constantly included in later blocks and trigger the DeductFee AnteHandler, which results in a slow depletion of account funds due to the constant payment of fees associated with a transaction that will fail. In short, this is what is happening:

1. The transaction is processed, and fees are payed lowering the balance.
2. The transaction fails.
3. The transaction is included in the next block.
4. Back to 1.

We found out this is caused by the fact that for a Profile instance the sequence is not increasing. This is due to how we currently handle SetX methods inside the Profile type:

// GetAccount returns the underlying account as an authtypes.AccountI instance
func (p *Profile) GetAccount() authtypes.AccountI {
	return p.Account.GetCachedValue().(authtypes.AccountI)
}

// SetSequence implements authtypes.AccountI
func (p *Profile) SetSequence(sequence uint64) error {
	return p.GetAccount().SetSequence(sequence)
}

As you can see, the SetSequence method relies on the GetAccount one, which returns the underlying cached account. Following, the SetSequence is called on that cached account.

The problem with this approach is that we're only updating the cached account, and not the real one. To solve this, we need to change all SetX implementations to something like the following:

// SetSequence implements authtypes.AccountI
func (p *Profile) SetSequence(sequence uint64) error {
    acc := p.GetAccount()
    err := acc.SetSequence(sequence)
    if err != nil {
        return err
    }

    accAny, err := codectypes.NewAnyWithValue(acc)
    if err != nil {
        return err
    }

    p.Account = accAny

    return nil
}

This will make sure that changes are also stored inside the underlying Any and not only it's cached value.

A test should also be added to make sure that this bug does not happen anymore.