Update auth_rules document to reflect the current defaults

[WadeBarnes]

The Default AUTH_MAP Rules document, although mostly accurate, does not fully reflect the default auth rules of a new indy-node network.

One example is the REVOC_REG_ENTRY ADD rule. The document states the owner of the corresponding REVOC_REG_DEF, regardless of role, can add new REVOC_REG_ENTRYs. The default auth_rules for the network on the other hand, indicate you need to be the owner of the corresponding REVOC_REG_DEF and have a signature from a Trustee, Steward, or Endorser.

Taken from a new network:

| REVOC_REG_ENTRY     | ADD    | *           | -             | *             | {                                |
|                     |        |             |               |               |   "auth_constraints": [          |
|                     |        |             |               |               |     {                            |
|                     |        |             |               |               |       "constraint_id": "ROLE",   |
|                     |        |             |               |               |       "metadata": {},            |
|                     |        |             |               |               |       "need_to_be_owner": true,  |
|                     |        |             |               |               |       "role": "0",               |
|                     |        |             |               |               |       "sig_count": 1             |
|                     |        |             |               |               |     },                           |
|                     |        |             |               |               |     {                            |
|                     |        |             |               |               |       "constraint_id": "ROLE",   |
|                     |        |             |               |               |       "metadata": {},            |
|                     |        |             |               |               |       "need_to_be_owner": true,  |
|                     |        |             |               |               |       "role": "2",               |
|                     |        |             |               |               |       "sig_count": 1             |
|                     |        |             |               |               |     },                           |
|                     |        |             |               |               |     {                            |
|                     |        |             |               |               |       "constraint_id": "ROLE",   |
|                     |        |             |               |               |       "metadata": {},            |
|                     |        |             |               |               |       "need_to_be_owner": true,  |
|                     |        |             |               |               |       "role": "101",             |
|                     |        |             |               |               |       "sig_count": 1             |
|                     |        |             |               |               |     }                            |
|                     |        |             |               |               |   ],                             |
|                     |        |             |               |               |   "constraint_id": "OR"          |
|                     |        |             |               |               | }                                |

It appears the rule for adding a new REVOC_REG_ENTRY was updated in mid 2019, but the documentation was not updated to reflect the change in code.

[WadeBarnes]

The indicated discrepancy in the documentation may actually be a bug in the code. The initial code associated to the above indicated changes happened here, 8d505a9, and is associated with this Jira ticket, https://jira.hyperledger.org/browse/INDY-1554. The acceptance criteria for the ticket (in both settings cases) indicates the owner of the REVOC_REG_DEF should be allowed to write new REVOC_REG_ENTRYs.

[WadeBarnes]

First step would be to determine if this particular discrepancy is a bug or intentional.

[WadeBarnes]

@mac-arrap, @VladimirWork, Do either of you recall this work?

[mac-arrap]

So what I remember is that this went through a lot of review by the evernym team but we didn't change the documentation. But I would feel a lot more comfortable if @ashcherbakov would confirm.

[WadeBarnes]

@mac-arrap, What's throwing me off right now is the acceptance criteria of the jira ticket matches what is indicated in the auth_rules documentation, but it does not match the default auth_rule (included above) that was implemented in the code.