6111 add multisig support

[aaronc]

/cc @clevinson

[auto-comment]

👋 Thanks for creating a PR!

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.

---

For contributor use:

• 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

---

For admin use:

• Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
• Reviewers assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

Thank you for your contribution to the Cosmos-SDK! 🚀

[clevinson]

Is this really necessary now? I would rather address specifics for the TEXTUAL mode at a later date when we actually begin fleshing them out.

e.g. If textual mode ends up being something more like a cleaner key-value representation (yaml, etc.) then we wouldn't need locale at all, right?

[clevinson]

Also, locale is not handled at all in the "multi" mode as this PR is written. Another reason why i think we should drop for now.

[aaronc]

I just added it so that we don't collapse Single into just the SignMode enum because we may want other fields describing the mode. I can remove, but Single should be a message not just the enum.

And yes it is handled in the multi mode. Study the Multi message a bit more

[clevinson]

This comment is confusing to me. It reads as if nested multisig public keys a possible signing mode, yet I don't see anything corresponding to "nested multisig public keys" in the mode enum.

[aaronc]

It wouldn't exist in the mode enum. It's a recursive set of ModeInfo messages

[aaronc]

For the latest design of the actual pub keys see #5997

[clevinson]

But at the proto level, this would be a flattened list of ModeInfo messages right? If I understand correctly, the purpose for including the ModeInfo list at all is only for accurate gas cost estimations.

Or does repeated have some support for recursive lists?