Add a setting to the Packages API to accept/reject revisions

Problem to solve

When publishing a package to your registry, you may or may not want to allow revisions to that package. For some organizations, a package version once created should be immutable. For others, they often will publish revisions to a package from their development or feature branches.

Right now we have a hybrid policy of allowing revisions, some formats allow it, others do not. So, we hear two different issues:

From the users that want to allow duplicates, they end up writing custom scripts in their .gitlab-ci.yml file to delete the existing version and republish it.
From the users that don't want to allow duplicates, it's a concern that if/when a duplicate is uploaded, we return the latest version of the package, which may not necessarily be correct.

Intended users

User experience goal

The goal is that it's easy for developers to use the Package Registry.

Proposal

Add a new endpoint to the Packages API that allows the user to specify if their registry should allow/disallow revisions. This will allow developers to define a policy that makes sense for their use case.

Default setting

In order to answer the question, what should the default setting be, we will be looking at the following data:

How many total packages have been published to .com? By format?
How many projects have packages published to them? How many have more than 10/100/1000?
How many packages are duplicates? By format? Snapshots?
How many projects have duplicate projects?

The above will also help us to determine how to handle updating existing registries. We do not want to introduce any breaking changes to existing pipelines.

Project vs Group vs Instance

A project-level setting would give the most fine-grained control. However, we should consider that an organization that really cares about package immutability may want an instance-level setting that says disallow revisions for all registries.

Further details

We asked the community if they thought we should allow/disallow duplicates or offer a setting for them to decide. The results are:

Permissions and Security

This action should be limited to project Admin

Documentation

Availability & Testing

What does success look like, and how can we measure that?

Success looks like organizations with strict compliance rules feel comfortable using the Packages feature. And teams for which that's not as important have the flexibility to work how they want to.

Metrics

We should measure each time the setting is updated, but also the total number of registries that allow vs. disallow revisions.