Implement links between permissions and message types

[nathanielhourt]

The only component of transaction authorization which is still missing is the links between the user's permissions (permission_objects) and message types ({code account, message type}). The contracts need to be written that allow the user to specify these links, and then chain_controller::lookup_minimum_permission must be updated to use these links to determine the minimum permission required for a given account to execute a message of a given type.

I propose adding these messages to the system contract:

struct requirepermission
   account AccountName
   code AccountName
   type FuncName
   requirement PermissionName

In the above, account will require the permission named in requirement in order to send messages of type to the code contract.

I propose adding a new object type:

class permission_link : public chainbase::object<permission_link_type, permission_link> {
   id_type id;
   AccountName account;
   AccountName code;
   FuncName message_type;
   PermissionName required_permission;
};

The object shall be indexed on {account, code, message_type} so that chain_controller::lookup_minimum_permission can map these values to required_permission, then use {account, required_permission} to look up the permission_object containing the authority account requires to invoke such messages.

Question: What happens if the user defines a permission_link with a valid required_permission name, but then removes or renames that permission? Options that come to mind are to forbid it (require the user to remove the link, rename the permission, and recreate the link?), or to automatically rename/delete the link. Thoughts?

[bytemaster]

A link to a undefined permission should be prevented on creation.
Removing a permission should update all links to point to the parent permission or remove the link if the parent permission is "active" as this is the implied default link.

Removing a permission should not be possible if there are child permissions. The child permissions should be removed first.

This makes "renaming" permissions very messy: create new permission, update links, remove old permission.

[nathanielhourt]

At this point everything should be implemented, and we're down to testing

[376726756]

good