Enhance CountAuthorization to have a sub-authorization field

[SpicyLemon]

Summary

Add a sub_authorization field to the CountAuthorization (defined in our SDK fork here).

Problem Definition

As a granter, I want to be able to enhance any authorization with a limit on the number of uses.

Proposal

Add a sub_authorization field to the CountAuthorization.

In the Accept, also call the Accept of the sub-authorization (if there is one) and handle it accordingly.

• If the sub-authorization's Accept says to delete, then the CountAuthorization's should say to too.
• If it returns an update, then the sub-authorization value needs the new updated value in the CountAuthorization.
• A CountAuthorization always returns either an updated version or to delete it.
• An error from the sub-authorization's Accept should be returned from the CountAuthorization's Accept.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[SpicyLemon]

Actually, I just realized that a better way might be to create a new multi-authorization.
It'd have a string msg for the type url and then a list of sub-authorizations.

All of the sub-authorizations would need to be for the same msg (type url).

When authorizing it, all sub-authorizations would need to be accepted. Once one of them hits "delete", the parent (and the other sub-authorizations) get deleted. If any of them return an update, the parent needs to be updated to have the new sub-authorization.

This would provide a versatile way to combine multiple authorizations, e.g. a CountAuthorization and a MarkerTransferAuthorization. With those two, the entire authorization would be deleted if either the count reaches zero, or the transfer limit reaches zero. I.e. I could say, "I'll allow Bob to do a transfer of up to 100bananas, but only once."

[SpicyLemon]

I've created the following issue from my previous comment:

• Create a multi-authorization. #2207

That would solve the same problem that this issue is trying to solve, but in a more generic way. So I'm gonna close this issue.