Offer a stock configuration of DAB RBAC models for system-wide permissions

[AlanCoding]

This proposes that we track permissions for models... that are used for tracking permissions.

Apps should already be able to do this themselves like

from ansible_base.rbac import permission_registry
from ansible_base.rbac.models import RoleDefinition

permission_registry.register(RoleDefinition, parent_field_name=None)

But this is unsatisfactory for a number of reasons. Firstly, the model RoleDefinition is owned by DAB itself, so the permissions are enumerated in the Meta class for the model, which the app has no control over. And clearly, the "view" permission makes no sense for that model, so only DAB can remove it for it to behave as expected.

This is expected to be somewhat opinionated, just as the API itself is. If you don't like it, build your own API.

Here is a spitball of some initial code changes for this:

https://github.com/ansible/django-ansible-base/compare/devel...AlanCoding:so_meta?expand=1

This has #475 as a dependency.

In that branch, I've included what I believe are the maximum permissions that we might enumerate. So while this removes some permissions, I could see us removing more.

• RoleDefinition
  • add
  • change
  • delete
• Assignment models
  • add
  • delete
  • view

My thought here is that we would only employ these as system-level permissions, if they are employed at all. An assignment, for instance, can be created if the user has the related permission to the content_object for that assignment. So generally, we shouldn't need to track an "add" permission. The only reason we would have this is to do a re-construct superuser permissions, so you could be a permission superuser, so you could give anyone any permission. I should say, I don't like that, because having the assignment "add" permission effectively gives you all other permissions (because you could assign yourself anything). So I find this somewhat incoherent. My minimal proposal would be:

• RoleDefinition
  • add
  • change
  • delete
• Assignment models
  • view

The idea is that we OR system-level permissions with other permissions. So if you have view permission to role assignments, you can view all role assignments regardless of your permissions to the content object of the assignment.

It is fairly coherent to allow normal users to create, change, and delete role definitions.