Endorser logic is overly restrictive

[dbluhm]

I think the author endorser code prevents the author from performing some operations that are actually permitted by the network.

As it stands, every operation that can generate a transaction requires the full transaction request exchange between the author and the endorser. However, the default Indy auth rules don't require an endorser to sign every transaction. See: https://hyperledger-indy.readthedocs.io/projects/node/en/latest/auth_rules/

To list the notable transaction types that don't require endorsement:

• Nym txns rotating a key (true also for diddocContent, though it's not specifically listed in the table linked above)
• attrib txns where the submitter is the owner of the nym of the attrib
• revocation registry entries

I have not yet verified my interpretation of these auth rules. But, even if it is true for the default values, these rules are, of course, configurable. One network may be more strict than another. I think this indicates that we should base the behavior of the endorser code on the current auth rules, obtained from the ledger to which we are attempting to publish.

Without this, we are overburdening endorsers with transactions they don't actually need to care about for the connected network. Additionally, not giving the author the ability to update their own nym directly potentially widens the window of vulnerability if a key is compromised. I'm not sure there's much value in the endorser gatekeeping that kind of an update to the ledger to begin with.

[dbluhm]

I confirmed using Indicio's test network (default auth rules right now) that my understanding of how the auth rules apply is correct.