feat: improve msg server, test aute handler

[PaddyMc]

What is the purpose of the change

• Added initial test cases for the ante handler
• Updated the checks in the msg_server.go
• Added comments to the proto file model

How to test

user1=$(osmosisd keys show user1 -a --keyring-backend=test)
pubkey=$(osmosisd keys show user1 -p --keyring-backend test | jq -r .key)

echo "y" | osmosisd keys add newKey1 --keyring-backend test 
pubkey1=$(osmosisd keys show newKey1 -p --keyring-backend test | jq -r .key)

echo "y" | osmosisd keys add newKey2 --keyring-backend test 
pubkey2=$(osmosisd keys show newKey2 -p --keyring-backend test | jq -r .key)

# this should fail
osmosisd tx authenticator add-authenticator SignatureVerificationAuthenticator $pubkey1 --from user1 --chain-id testing --keyring-backend test --fees 1000stake -b sync -y

sleep 4

osmosisd tx authenticator add-authenticator SignatureVerificationAuthenticator $pubkey --from user1 --chain-id testing --keyring-backend test --fees 1000stake -b sync -y

sleep 4

osmosisd tx authenticator add-authenticator SignatureVerificationAuthenticator $pubkey2 --from user1 --chain-id testing --keyring-backend test --fees 1000stake -b sync -y

sleep 4

osmosisd tx authenticator add-authenticator SignatureVerificationAuthenticator $pubkey1 --from user1 --chain-id testing --keyring-backend test --fees 1000stake -b sync -y

osmosisd q authenticator authenticators $user1 --output json | jq 

[nicolaslara]

we should probably move this to x/authenticator/authenticator/signature_authenticator.go

[PaddyMc]

Done 👍

[nicolaslara]

Note: When the FE is doing this, it could send a multimsg to add multiple authenticators. (sigVer for account, anything else)

[PaddyMc]

I think the messages will be processed one by one, so SigVer for account, then added to the authenticator store, then one for spend limits added to the authenticator store

[nicolaslara]

Like we discussed in the call. This could be replaced by: authenticator.Validate(account, msg.Data) or authenticator.OnAuthenticatorAdded(account, msg.Data). But that doesn't need to block this PR, we can just add it on top

[PaddyMc]

I'll add that next 💪

[nicolaslara]

I don't think we can call validate here without a redundant call to m.Keeper.GetAuthenticatorsForAccount(ctx, sender)

[PaddyMc]

I think we could use authenticator.Validate(msg.Sender, msg.Data), when it's written

[nicolaslara]

left some comments, but looks great in general. Happy to merge it

[nicolaslara]

I find these a bit hard to read. Maybe we could do something like

type TxGenConfig struct {
    Gen     client.TxConfig
    FeeAmt  sdk.Coins
    Gas     uint64
    ChainID string
}

type AccountInfo struct {
    AccNums []uint64
    AccSeqs []uint64
}

type KeyInfo struct {
    Signers    []cryptotypes.PrivKey
    Signatures []cryptotypes.PrivKey
}

func GenTx(
    config TxGenConfig,
    msgs []sdk.Msg,
    accountInfo AccountInfo,
    keyInfo KeyInfo,
) (sdk.Tx, error) 
...

txConfig := TxGenConfig{
        Gen:     s.EncodingConfig.TxConfig,
        FeeAmt:  feeCoins,
        Gas:     300000,
        ChainID: "",
}

tx, _ := GenTx(
    txConfig,
    []sdk.Msg{
        testMsg1,
        testMsg2,
    },
    AccountInfo{
        AccNums: []uint64{0, 0},
        AccSeqs: []uint64{0, 0},
    },
    KeyInfo{
        Signers: []cryptotypes.PrivKey{
            s.TestPrivKeys[0],
            s.TestPrivKeys[1],
        },
        Signatures: []cryptotypes.PrivKey{
            s.TestPrivKeys[1],
            s.TestPrivKeys[1],
        },
    },
)

[PaddyMc]

Defo, I'll be working on more tests today, would you mind if I added this to the next PR?

Happy to add it here as well, lmk what you think?