Make "keep latest artifact" an instance-level configuration

What does this MR do?

Adds an option in application settings that allows a user to enable or disable the 'keep latest artifact' functionality which preserves the artifacts from the latest pipeline run. It currently does this by 'locking' artifacts when a pipeline is first created and then and then unlocking them when new pipelines for the same branch succeed.

Locking explained: Artifacts for unlocked pipelines will expire according to normal expiration policies and artifacts with locked pipelines will never expire and currently.

This MR also provides querying mechanisms so that the project settings page which also has this setting applied to the project level can determine when to disable the checkbox.

Issue #276583 (closed)

Technical implementation

Add column

Adds a applications setting column for keeping the latest artifact

Add graphql query

Add Application setting to the root query in graphql with the keep latest artifact setting. This is to be used by the front end to disable the project level setting when the instance level setting is enabled:

query {
  ciApplicationSettings {
    keepLatestArtifact
  },
  project(fullPath: "root/merge-trains") {
    id,
    ciCdSettings {
      keepLatestArtifact
    }
  }
}

Add Application setting to public API

This is just for completeness of the API for customers programmatic needs (since most application settings are not yet in graphql)

haml/REST applications settings page

Because of design constraints, we could not port this page to vue and graphql at this time.

Database output

I did not add lock retries because the application_settings table has only 1 row on GitLab.com.

UP

exec ALTER TABLE “application_settings” ADD “keep_latest_artifact” boolean DEFAULT TRUE NOT NULL;

The query has been executed. Duration: 43.000 ms (edited) 

Down

exec ALTER TABLE "application_settings" DROP COLUMN "keep_latest_artifact"

The query has been executed. Duration: 12.000 ms 

Screenshots (strongly suggested)

Application Settings

before	after

Project disabled state based on instance

Instance	Project

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