Protected containers: Add basic model and migrations for protecting container

Context

• In &9825 (comment 1461465889), we already discussed the scope and implementation details for the initial version of the container protection feature
• This issue wants to cover the first steps of the proposed implementation plan involving:
  • Add model for ContainerRepositoryProtectionRule
  • Adding the basics for protecting containers, see #424367 (closed)

🛠 with ❤ at Siemens

Proposal

• The proposed implementation is described in a comment (section Implementation proposal) as part of the EPIC.

• We want to implement this feature with backward compatility in mind => this means that we do not want to migrate any existing data

• We want to maintain the current permissions for interacting with the container registry => therefore, the model ContainerRegistry::Protection::Rule is an additional permission => hence, we do not need to migrate the existing data model

• When a container-specific ContainerRegistry::Protection::Rule exists then this policy is enforced

• When no container-specific ContainerRegistry::Protection::Rule exists then the default container permissions are applied => this ensures backward compatibility

• The field push_protected_up_to_access_level represents the (mininum) user access level for which the container is protected, i.e. the container is protected from any user access level less than or equal to this field

• The field container_path_pattern should be unique per project_id

classDiagram
  class `ContainerRegistry::Protection::Rule`{
    id bigint,
    container_path_pattern string
    push_protected_up_to_access_level Gitlab::Access
    delete_protected_up_to_access_level Gitlab::Access <= this is out of scope for now
    project_id bigint
  }
  `ContainerRegistry::Protection::Rule` --> `Project`
  `ContainerRepository` --> `Project`

In !124776 (merged), we worked on a feature regarding package protection. During the implementation and review of this feature, new learnings and aspects came up that could also be considered here:

• GitLab instance admin should always be able to write, update and delete new containers even when these containers are not protected by a container protection rule => hence, Gitlab::Access::NO_ACCESS is not an valid option for push_protected_up_to_access_level

Checklist

• Add data model
• Add database migration
• Add tests for data model