Optional parties and party/signer/role validation overhaul

[SpicyLemon]

Description

closes: #1381
closes: #1437
closes: #1438

Primarily, this PR:

• Adds a require_party_rollup boolean field to the scope, and an optional boolean field to the Party message
• When require_party_rollup = true, new signer validation is used (see spec docs for full details) and optional = true parties are allowed in the scope and it's sessions. Otherwise, optional = true parties are not allowed and existing signer logic is applied.
• When a spec has repeated roles, an equal number of parties with that role and different addresses are required. This is independent of the require_party_rollup and optional change.
• The address for parties with the role PROVENANCE MUST be for a smart contract account. And any parties that have a smart contract account address must MUST have the PROVENANCE role. In other words, smart contracts MUST use the PROVENANCE role, and only smart contracts can use the PROVENANCE role.
• The AddScopeOwner endpoint no longer updates the role of an existing entry with the same address as the one provided. It now simply adds the provided owner.

Secondarily, this PR:

• Speeds up make proto-format.
• Fixes some typos in the protos.
• Moves the cli argument parsing helpers into their own file and adds unit tests on them.
• Moves some of the keeper.go and signatures.go stuff into signers.go and signers_utils.go and refactors some more of that stuff.
• Switches the metadata keeper to use interfaces for the auth and authz keepers and creates mocks for those so that unit testing can be a little easier in there.
• Adds a bunch of unit tests that were missing.
• Uses auto-generated .String() funcs for the metadata Msgs.
• Removes the no-longer-needed .MsgTypeURL() funcs from the Msgs.
• Renames the keeper's Validate...Update functions to Validate<endpoint>, e.g. ValidateWriteScope instead of ValidateScopeUpdate.

---

Overview of new signer validation

New signer validation is used for scopes, sessions, and records where the scope has require_party_rollup = true. For such scopes, all parties in any of its sessions must also be included in the scope's owners.

• Any scope owners with optional=false are required to sign for any scope updates including its sessions and records.
• Any session parties with optional=false are required to sign for updates to that session as well as the records being written under that session.
• A party can be optional=false in the scope and optional=true in a session, and vice versa.
• If a party is in multiple sessions in the same scope, it only needs to be in the scope owners once. It can also have different optional values in each session.

Then, coordination is done with the specification, parties, and signers to possibly require additional signatures (beyond the optional=false ones). The roles defined in the specification dictate which parties need to sign. For each required role, there needs to be a unique party that is also a signer.

For example:

• A record spec requires a SERVICER.
• A session that will contain that record has three parties:
  • Address :A, Role:OWNER, Optional: false
  • Address :B, Role:SERVICER, Optional: true
  • Address :C, Role:SERVICER, Optional: true

In order to write that record, address A must be a signer because it is optional=false in the session.
Then, EITHER address B or C must be a signer because the specification requires a SERVICER (and address A is not one).

In that above example, if the record spec instead requires SERVICER, SERVICER, then both B and C would need to sign since they are the only SERVICER entries, and two different ones are required.

Then, if, there were a forth party in the session: Address :D, Role:SERVICER, Optional: true (and two SERVICERs are required), any two of B, C, and D must sign.

In all of this, consideration is still made for x/authz authorizations. It's possible for a single signer to fulfill all signing requirements if other parties have granted them authorization. They can even fulfill the signing requirements for multiple of the same role as long as there are enough different parties that have given them authorizations.

For example:

• A contract spec requires VALIDATOR, VALIDATOR, OWNER.
• The session has these parties:
  • Address :A, Role:OWNER, Optional: true
  • Address :B, Role:OWNER, Optional: true
  • Address :C, Role:VALIDATOR, Optional: true
  • Address :D, Role:VALIDATOR, Optional: true
  • Address :E, Role:VALIDATOR, Optional: true
• There are also two addresses not directly involved in the session: Address F, and G.
• The following authorizations have been granted for writing sessions:
  • Grant 1: Granter: C, Grantee: B
  • Grant 2: Granter: D, Grantee: B
  • Grant 3: Granter: A, Grantee: F
  • Grant 4: Granter: D, Grantee: F
  • Grant 5: Granter: E, Grantee: F
  • Grant 6: Granter: A, Grantee: C
  • Grant 7: Granter: A, Grantee: G
  • Grant 8: Granter: C, Grantee: G

The session can be written with any of these collections of signers (not an exhaustive list):

• B - They fulfill the OWNER spec requirement themselves. Because of grants 1 and 2, their signature can fulfill two different VALIDATOR roles from C and D.
• F - An OWNER and two different VALIDATORs have granted them the ability to sign on their behalf (grants 3, 4, and 5). So all three requirements are satisfied.
• C and D - Both C and D can individually fulfill the two VALIDATOR requirements. Then because of grant 6, C is allowed to sign for A, and A is an OWNER. So C's signature also covers the OWNER requirement.
• G and E - The signature from E covers one of the two VALIDATOR requirements. Then G, because of grants 7 and 8, can sign for C (another VALIDATOR), and A (an OWNER).

Authorizations are not transitive though. Grant 1 says that B can sign on behalf of C, and grant 6 says that C can sign on behalf of A. That does not mean that B can sign on behalf of A.

---

One problem all of this solves is when a scope owner wants to give someone (e.g. a SERVICER) permission to write sessions/records in a certain subset of scopes.

The owner would list themselves as optional=false in the scope, probably with the role OWNER (really, anything but SERVICER). Then, they'd list the servicer as optional=true in the applicable scopes. The contract specs and record specs would then need to require a SERVICER. Lastly, the owner would issue an authz grant allowing them to write sessions and records on their behalf.

Now, the servicer can write their sessions records to those scopes using only their signature. However, they wouldn't be allowed to write those sessions and records to other scopes because a SERVICER signature is required, and they are not listed as such in those scopes.

---

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.
• 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

[iramiller]

High level review of changes complete. Overall this looks good!

[iramiller]

With the recent updates all tests/checks are passing.

[iramiller]

Massive code coverage now... nice work.