Add flavor permission rules

[seb-kro]

Flavor access is currently controlled via private/public flavors and the flavor access list aka FlavorProjects. To restrict access to a flavor, it must be turned private and access must be granted individually to each project.

This adds flavor permission rules for a more flexible flavor permission management. These rules are independent of flavor privacy and the flavor access list. So a flavor is only available to a project if allowed by both the flavor permission rules and the flavor access list.

There are two types of flavor permission rules: allow and deny. deny rules take precedence over allow rules. Rules without a flavor_id define the project default behavior for flavors without a flavor-specific rule. If a domain or a project does not define any rules, then all flavors are permitted by default.

Depending on the specified project_id, flavor permission rules have two different scopes:

• domain-level rules apply to all projects within the domain
• project-level rules apply only to the project itself and are not inherited by sub-projects A flavor is permitted for a project if it is permitted at both the domain and project level.

There is at most one flavor permission rule for each combination of project_id and flavor_id. Consequently, a flavor is permitted at the domain- or project level if for that level:

• No rules are defined
• OR there is an allow rule matching the flavor
• OR there is an allow rule without a flavor_id AND there is no deny rule matching the flavor

Change-Id: I5e1332d111c07ee714f2965c558f393c8568ffaf