Add setting to allow Maven package duplicates

🌲 Context

Users can publish Maven packages to the GitLab package registry. Maven packages are identified by their name and version.

Currently, if a user uploads a package with the same name and version more than once, both uploads are successful, and both packages will be stored in the registry. Only the most recent will be returned if a user attempts to install the package. This is a commonly used pattern in Maven for "Snapshot" versions. It is normal for users to continuously update the same version, for example 1.0.0-SNAPSHOT until they are ready to release it, at which time, it is uploaded as version: 1.0.0. Some users, however would prefer if GitLab reject the duplicate, or they would like if they had the option to specify which versions do and do not allow duplicates.

To accomplish this, we will add two new settings at the namespace level for users to set. First, we have maven_duplicates_allowed. Which is a boolean to say whether or not duplicates are allowed. It is set to true by default in order to follow the rules already followed by the package registry. Second, we have maven_duplicate_exception_regex, which will allow users to specify what packages to allow duplicates for if maven_duplicates_allowed is set to false. An example is a user might disallow duplicates, but use .*SNAPSHOT as their maven_duplicate_exception_regex to allow duplicates for any versions ending in "SNAPSHOT".

This MR begins the implementation of these settings.

⚙ What does this MR do?

1. Creates a new table namespace_package_settings that will be used to hold any namespace-level settings for the GitLab package registry.
2. This new table contains two initial settings for use with Maven packages: maven_duplicates_allowed and maven_duplicate_exception_regex.
3. Creates the new NamepacePackageSetting model and associates it with Namespace, setting it up so that any new namespaces will automatically get an associated NamespacePackageSetting with the default values.
4. Adds GraphQL Type and Mutation for querying and updating NamespacePackageSetting.

🚫 What this MR does not do

1. We do not use the settings yet. A separate MR will update the Maven package creation code to use and enforce these settings.
2. There is no frontend for users to update the settings yet. A separate MR will update the frontend using the GraphQL updates from this MR.

🐘 Database

Up migration

== 20201215205404 CreateNamespacePackageSettings: migrating ===================
-- create_table(:namespace_package_settings, {:if_not_exists=>true, :id=>false})
   -> 0.0082s
-- transaction_open?()
   -> 0.0000s
-- current_schema()
   -> 0.0002s
-- execute("ALTER TABLE namespace_package_settings\nADD CONSTRAINT check_d63274b2b6\nCHECK ( char_length(maven_duplicate_exception_regex) <= 255 )\nNOT VALID;\n")
   -> 0.0005s
-- current_schema()
   -> 0.0002s
-- execute("SET statement_timeout TO 0")
   -> 0.0003s
-- execute("ALTER TABLE namespace_package_settings VALIDATE CONSTRAINT check_d63274b2b6;")
   -> 0.0008s
-- execute("RESET ALL")
   -> 0.0003s
== 20201215205404 CreateNamespacePackageSettings: migrated (0.0223s) ==========

Down migration

== 20201215205404 CreateNamespacePackageSettings: reverting =======================
-- drop_table(:namespace_package_settings)
   -> 0.0146s
== 20201215205404 CreateNamespacePackageSettings: reverted (0.0148s) ==============

📷 Screenshots (strongly suggested)

Updating a NamespacePackageSetting:

Reading a NamespacePackageSetting:

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

Related to #276882 (closed)