Add pre_receive_secret_detection_enabled application setting

What does this MR do and why?

This merge request introduces a new application setting: pre_receive_secret_detection_enabled.

It also updates the secrets push check from !135036 (merged) and !135032 (merged) to honor this new setting when running the check.

Resolves #428760 (closed), built on top of !135036 (merged) and !135032 (merged).

Migrations

The following excerpt is from db:check-migrations job:

$ git diff --name-only --diff-filter=A make-secrets-check-an-ultimate-feature -- db/migrate db/post_migrate
db/migrate/20231028191217_add_pre_receive_secret_detection_enabled_to_application_settings.rb
$ scripts/db_tasks db:migrate:down VERSION=20231028191217
Running: `bundle exec rake db:migrate:down:main VERSION=20231028191217`
main: == [advisory_lock_connection] object_id: 175440, pg_backend_pid: 121
main: == 20231028191217 AddPreReceiveSecretDetectionEnabledToApplicationSettings: reverting 
main: -- remove_column(:application_settings, :pre_receive_secret_detection_enabled, :boolean, {:null=>false, :default=>false})
main:    -> 0.0027s
main: == 20231028191217 AddPreReceiveSecretDetectionEnabledToApplicationSettings: reverted (0.0138s) 
main: == [advisory_lock_connection] object_id: 175440, pg_backend_pid: 121
$ scripts/db_tasks db:schema:dump
Running: `bundle exec rake db:schema:dump:main`
$ git diff make-secrets-check-an-ultimate-feature -- db/structure.sql
$ scripts/db_tasks db:migrate
Running: `bundle exec rake db:migrate:main`
main: == [advisory_lock_connection] object_id: 175180, pg_backend_pid: 153
main: == 20231028191217 AddPreReceiveSecretDetectionEnabledToApplicationSettings: migrating 
main: -- add_column(:application_settings, :pre_receive_secret_detection_enabled, :boolean, {:null=>false, :default=>false})
main:    -> 0.0039s
main: == 20231028191217 AddPreReceiveSecretDetectionEnabledToApplicationSettings: migrated (0.0110s) 
main: == [advisory_lock_connection] object_id: 175180, pg_backend_pid: 153

Related merge requests

Step	Merge Request	Description
1	!135032 (merged)	Adds the secrets push check, and puts it behind a feature flag.
2	!135036 (merged)	Updates the secrets push check to check for license (only ultimate is allowed).
3	This one	Adds a new application setting for pre-receive SD, and updates the secrets push check accordingly.
4	!135273 (merged)	Adds the UI for toggling the application setting of pre-receive SD

Why are we introducing a feature flag and an application setting at the same time?

In the related merge requests (as shown above), we introduce an application setting (configurable via the UI) in addition to the feature flag introduced in this merge request, the reason is because this feature is planned for GitLab Dedicated first, and then for other types of instances.

GitLab Dedicated, however, does not support feature flags, and since this is an experimental feature at the moment, the solution is to put the feature behind an application setting (introduced in step number 3) for dedicated instances, and for all other types to have the feature behind the same application setting and a feature flag enabled per project.

Please read more about this decision in this thread.

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.