Add fee payer to protobuf definition

[ethanfrey]

Description

closes: #7341

• Adds a new field: Tx.AuthInfo.Fee.Payer
• Update Tx.FeePayer() to use this field if set, otherwise default to first signer if unset (current status)
• Update Tx.GetSigners() to ensure the fee payer is included - appended at the end if not in any messages

This allows us to specify the non-first signer to pay the fee in a multi-sig transaction. It also allows us to provide something like Ethereum's "meta-transactions". I can sign a transaction I wish and name a third-party as the fee payer. They can parse the transaction and then sign on to pay the fee for me. Incentivation schemes are out of scope, but we give stargate the infrastructure to let people experiment.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[codecov]

Codecov Report

Merging #7384 into master will increase coverage by 0.00%.
The diff coverage is 60.00%.

@@           Coverage Diff           @@
##           master    #7384   +/-   ##
=======================================
  Coverage   54.81%   54.81%           
=======================================
  Files         587      587           
  Lines       36502    36512   +10     
=======================================
+ Hits        20008    20014    +6     
- Misses      14404    14406    +2     
- Partials     2090     2092    +2     

[ethanfrey]

This was working on make test. Then I rebased from 7ea6b2c5e to 0ddb2bd74 (one day of master commits) and some integration tests fail. It has the same behavior when fee payer is unset, so I am confused.

And just 2 of the 4 test runs...

[aaronc]

What will we do here when we have fee grants working?

[ethanfrey]

I think fee grants will be enough of a project that we do some more refactoring then.

My first idea was "Refactor this code and make changes to the various ante handlers.". However, on reflection, the current functionality is actually quite useful with no more and should not be removed. Maybe fee grants could add a separate field to specify a grant. eg.

message Fee {
  repeated cosmos.base.v1beta1.Coin amount = 1;
  uint64 gas_limit = 2;
  string payer = 3;
  string granter = 4;
}

• payer and granter unset is as now (paid from first signer)
• payer set and granter unset is like my PR (paid from specified payer, who is added to signers)
• payer set and granter set means the payer (who signed) will attempt to pay the fees via a fee grant from granter's account.
• payer unset and granter set is either invalid or says the first signer attempts to pay from the granter's account

This is just my first reflection. We could add this granter field by 0.40 if you wish, but I would make that a separate PR, and not worry about implementing that until the fee grant module (which may be 0.40.x if you add the field now, or maybe 0.41)

[aaronc]

I guess that could work. It does add the overhead of another field, but it does seem clearer and allow the additional third use case you've specified.

[ethanfrey]

@anilcse if I have satisfactorily addressed your change request, can you please leave another review? I'd prefer to remove the red flag now that I have fixed it

[anilcse]

lgtm

[ethanfrey]

Thanks

[alessio]

@ethanfrey please merge master in

[amaury1093]

lgtm

[ethanfrey]

What is blocking this PR? Besides the merge conflict? There is rapid bit rot in the SDK as other PRs merge in, so it would be nice to see this moving forward.

When I auto-gen proto files, they do look a bit different than the checked in ones. And this is showing a diff in the auto-gen file, I wonder if I can do this merge properly...

[aaronc]

I've added automerge. Just fix the conflicts and it should merge.