Add Sentry config to application settings

What does this MR do and why?

This is the first step for the Sentry migration to the newest version. The plan is to support both version until %15.0 and use feature flags to configure which Sentry should receive the events.

The old Sentry configuration lives in the gitlab.rb config file, but we don't accept any new entries to the file and it's recommended to use the ApplicationSetting model instead.

This is extracted from !72428 (merged)

Database migration output

$ bin/rails db:migrate:up VERSION=20211021125908
== 20211021125908 AddSentrySettingsToApplicationSettings: migrating ===========
-- add_column(:application_settings, :sentry_enabled, :boolean, {:default=>false, :null=>false})
   -> 0.0072s
-- add_column(:application_settings, :sentry_dsn, :text)
   -> 0.0010s
-- add_column(:application_settings, :sentry_clientside_dsn, :text)
   -> 0.0010s
-- add_column(:application_settings, :sentry_environment, :text)
   -> 0.0012s
== 20211021125908 AddSentrySettingsToApplicationSettings: migrated (0.0106s) ==

$ bin/rails db:migrate:down VERSION=20211021125908
== 20211021125908 AddSentrySettingsToApplicationSettings: reverting ===========
-- remove_column(:application_settings, :sentry_environment, :text)
   -> 0.0061s
-- remove_column(:application_settings, :sentry_clientside_dsn, :text)
   -> 0.0013s
-- remove_column(:application_settings, :sentry_dsn, :text)
   -> 0.0014s
-- remove_column(:application_settings, :sentry_enabled, :boolean, {:default=>false, :null=>false})
   -> 0.0039s
== 20211021125908 AddSentrySettingsToApplicationSettings: reverted (0.0170s) ==

$ bin/rails db:migrate:up VERSION=20211021134458
== 20211021134458 AddLimitsToSentrySettingsOnApplicationSettings: migrating ===
-- transaction_open?()
   -> 0.0000s
-- current_schema()
   -> 0.0003s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE application_settings\nADD CONSTRAINT check_4f8b811780\nCHECK ( char_length(sentry_dsn) <= 255 )\nNOT VALID;\n")
   -> 0.0052s
-- current_schema()
   -> 0.0002s
-- execute("SET statement_timeout TO 0")
   -> 0.0005s
-- execute("ALTER TABLE application_settings VALIDATE CONSTRAINT check_4f8b811780;")
   -> 0.0013s
-- execute("RESET statement_timeout")
   -> 0.0005s
-- transaction_open?()
   -> 0.0000s
-- current_schema()
   -> 0.0002s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE application_settings\nADD CONSTRAINT check_3def0f1829\nCHECK ( char_length(sentry_clientside_dsn) <= 255 )\nNOT VALID;\n")
   -> 0.0011s
-- current_schema()
   -> 0.0002s
-- execute("ALTER TABLE application_settings VALIDATE CONSTRAINT check_3def0f1829;")
   -> 0.0013s
-- transaction_open?()
   -> 0.0000s
-- current_schema()
   -> 0.0002s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE application_settings\nADD CONSTRAINT check_5bcba483c4\nCHECK ( char_length(sentry_environment) <= 255 )\nNOT VALID;\n")
   -> 0.0010s
-- current_schema()
   -> 0.0002s
-- execute("ALTER TABLE application_settings VALIDATE CONSTRAINT check_5bcba483c4;")
   -> 0.0013s
== 20211021134458 AddLimitsToSentrySettingsOnApplicationSettings: migrated (0.0494s)

$ bin/rails db:migrate:down VERSION=20211021134458
== 20211021134458 AddLimitsToSentrySettingsOnApplicationSettings: reverting ===
-- transaction_open?()
   -> 0.0000s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE application_settings\nDROP CONSTRAINT IF EXISTS check_4f8b811780\n")
   -> 0.0017s
-- transaction_open?()
   -> 0.0000s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE application_settings\nDROP CONSTRAINT IF EXISTS check_3def0f1829\n")
   -> 0.0011s
-- transaction_open?()
   -> 0.0000s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE application_settings\nDROP CONSTRAINT IF EXISTS check_5bcba483c4\n")
   -> 0.0011s
== 20211021134458 AddLimitsToSentrySettingsOnApplicationSettings: reverted (0.0316s)

Screenshots or screen recordings

I added the config form to admin/application_settings/metrics_and_profiling, but I'm open to suggestions about a better home for it.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.