Allow max includes to be changed in application settings

What does this MR do and why?

This MR converts the hardcoded limit of MAX_INCLUDES into an application setting ci_max_includes. The application setting can be changed via the UI in Admin Settings or updated via the API.

This setting affects how many include files are allowed in the CI pipeline config. The default value is 150.

Resolves #207270 (closed)

Screenshots

New Maximum includes setting in Admin > Settings > CI/CD > Expand "Continuous Integration and Deployment"

How to set up and validate locally

1. Run the migration: bundle exec rails db:migrate
2. Set up a circular includes situation so that we can easily see the current maximum includes value being used. You can do this by updating your project's .gitlab-ci.yml with the following:

include: .gitlab-ci.yml

When you attempt to run the pipeline you should see the following error. Notice that the default value is 150.

3. Change the application setting via the UI. Go to Admin > Settings > CI/CD > Expand "Continuous Integration and Deployment" and change the value of Maximum includes to 123. Click "Save changes".

Attempt to run the pipeline again and observe that the error now shows 123.

Screenshot

4. Change the application setting via the api by running the following command in the terminal. (Adjust the host and token as needed).

curl --request PUT --header "PRIVATE-TOKEN: <your-access-token>" "http://gdk.test:3000/api/v4/application/settings?ci_max_includes=95"

Observe that the response shows the updated value:

You can also attempt to run the pipeline again and observe that the error now shows 95.

Screenshot

5. Just for extra measure, and to ensure we haven't just been updating the error message (😆), we can update the setting to 2.

Create a child.yml file with the following content:

job:
  script: echo

Then update your .gitlab-ci.yml with 3 include files like so:

include:
  - local: child.yml
  - local: child.yml
  - local: child.yml

Run the pipeline and observe that there is a validation error.

Screenshot

And if you then update your .gitlab-ci.yml with just 2 include files, there is no validation error and the pipeline runs successfully. 🤗

Migration

bundle exec rails db:migrate

main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrating ============
main: -- add_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
main:    -> 0.0048s
main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrated (0.0142s) ===

ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrating ============
ci: -- add_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
ci:    -> 0.0047s
ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: migrated (0.0110s) ===

VERSION=20230421165020 bundle exec rails db:migrate:down:main

main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverting ============
main: -- remove_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
main:    -> 0.0024s
main: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverted (0.0080s) ===

VERSION=20230421165020 bundle exec rails db:migrate:down:ci

ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverting ============
ci: -- remove_column(:application_settings, :ci_max_includes, :integer, {:default=>150, :null=>false})
ci:    -> 0.0024s
ci: == 20230421165020 AddCiMaxIncludesToApplicationSettings: reverted (0.0113s) ===

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.

Related to #207270 (closed)