Allow disabling object-level permissions for a given model in the RBAC registry

[AlanCoding]

This is a "model registration flexibility" issue similar to #365

The ask here is to allow disabling of using object-level roles for a particular model. Spitball of the contract for this:

permission_registry.register(Instance, allow_object_roles=False)

We would have allow_object_roles default to True, as this is how it is always used today. With this change, the /api/v1/role_metadata/ endpoint would not show the content type for the Instance model (see later notes). However, importantly, the permissions related to the Instance model would still be shown as possible for system-wide roles. This is a valid use-case for this feature, because you may want to allow someone to manage instances in AWX without making them a superuser, but you still don't want to build out a UI for giving permissions to single instances, because you just don't want that.

The AWX Instance model does not have a related organization, but you could repeat for an organization-scoped model.

Our use case for this second version (org-scoped) mode would be the OAuth2 Application model. In AWX organization admins got permissions to this model. Implementation here would be that the model's permissions are listed in the organization admin roles. Optionally, someone could create custom organization-level roles that include OAuth2 Application permissions. But a user would not be able to create custom roles that give permission to individual applications, simply because we do not want to build a UI for this.

[AlanCoding]

@relrod my only hangup for doing a fast 30-minute version of this is where this data could live. Right now the permission_registry keeps some simple dictionaries and sets that were introduced for specific problems.

• We could introduce another... set on permission_registry that lists model names that don't allow object roles? That would get the job done.
• Another option to ninja this in would be that we could take the model class itself and do something like setattr(cls, '_allow_object_roles', True), and then use that flag on the objects themselves in the serializer.

Thinking it over, I'm okay with either approach.

[AlanCoding]

This has a problem with the need for "creator" roles after someone creates a new object and does not have a role which would give implicit access to that object. Options for ways around that are:

1. For this type of model, require that the "add" permission is coupled with all other permissions. You can't have a role with "add" permission by itself.
2. Prohibit the "add" permission for models that have no object-level roles and use "change", "delete", or "view" permissions as proxy. This is complex and confusing.
3. Still allow system object-level roles but prevent custom object-level roles. But how would we communicate this to clients?

None of these options are slam dunks. If I were to choose one, I would lean towards (1). However that still leaves unanswered questions.

Also, a half-way option that looks like option (3) will be possible with #490. Drawback is that it blocks the action late in the user experience, as opposed to giving advance notice to clients. On the other hand, it can offer a detailed rationale which needs to be filled in by the specific model permission policies.

Those together make this a pretty solid won't-fix.

[AlanCoding]

This is now coming back up for galaxy_ng, and we will be getting a model list for this for those models.

[AlanCoding]

Link prior work for this #475