Optionally use new dry_run mode on CI Lint page

What does this MR do?

Related to #229794 (closed)

In !37134 (merged) we introduced a new mode in Ci::CreatePipelineService called dry_run: true which would skip persisting the pipeline while letting everything else happening. In the end, a non-persisted pipeline is returned including any errors and (recently added) warnings.

In this MR we change the CI Lint web page to use the dry_run mode and pass in the content to validate.

Feature Flag

These changes are done behind a feature flag disabled by default: ci_lint_creates_pipeline_with_dry_run. After deployment to production the FF will be enabled and a MR will be created with changing it to default_enabled: true.

Limitations

This feature currently uses some static parameters like ref, :push source but we could add a form in the UI to allow users insert custom parameters to simulate different contexts (various sources like schedule, merge requests, etc. - ref - variables - commit message - etc). Because of that only maintainers (with permissions to run pipelines on master) can see and use this feature, until other parameters will be supported.

Performance

• Given that we will be using the full pipeline creation process rather than just YamlProcessor we expect that response times to CI lint controller and API will increase.

Screenshots

Using dry run mode

• check the checkbox - the (?) icon should bring the user to the documentation page
• click Validate button

Before (checkbox disabled)

Certain validations that occurred at an advanced stage of pipeline creation are not caught by the current CI Lint (default mode).

After (checkbox enabled)

With dry run enabled we are able to provide the actual errors.

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