Add configurable allow_failure scan setting for scan execution policies

What does this MR do and why?

Scan execution policies inject security scan jobs to enforce that scans run. All scan templates (Jobs/SAST, Jobs/Secret-Detection, Jobs/Container-Scanning, Jobs/Dependency-Scanning, Jobs/SAST-IaC) set allow_failure: true by default, so a failing injected scanner does not block the pipeline or the MR, and the scan cannot be enforced through merge request approval policies.

This MR adds an allow_failure scan setting to the scan execution policy action. When present, its value is applied to every injected job in CiAction::Template#config:

• allow_failure: false — a failed scan job fails the pipeline, making the scan enforceable (a failed scan is treated as not-succeeded by enforce_scan_completion! in merge request approval policies).
• allow_failure: true — injected jobs are explicitly allowed to fail.
• unset — the scan template's own default is preserved (backward compatible).

This replaces the earlier unconditional allow_failure: false override (which changed behavior for every policy) with an opt-in, per-policy setting. It works across all scan types and template versions, since the value is written onto the built job configuration rather than depending on a template input.

Schema

Both the scan execution policy content schema (scan_execution_policy_content.json) and the umbrella security orchestration policy schema used for DB persistence validation (security_orchestration_policy.json) accept the new allow_failure setting.

Policy editor UI

The policy editor UI toggle for this setting is delivered in a follow-up MR: !247084 (closed).

Related issue

#604648

Configuration example

scan_execution_policy:
- name: Enforce dependency scanning
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: dependency_scanning
    template: v2
    scan_settings:
      allow_failure: false

How to set up and validate locally

This reproduces the scenario from issue 604648 where a dependency scanning job fails but the pipeline was not blocked.

1. Create a new project with a .gitlab-ci.yml that includes a security scan template (for example Jobs/Dependency-Scanning.v2.gitlab-ci.yml) and a manifest that causes the scan to fail.
2. Create a scan execution policy with scan_settings.allow_failure: false on the scan action (see the example above).
3. Open a merge request and run the pipeline.

Observation: the injected scan job is generated with allow_failure: false, so a scan failure fails the pipeline and the merge request approval policy requires approval. With the setting unset, the job keeps allow_failure: true and the pipeline is unaffected (previous behavior).

Tests

• ee/spec/services/security/security_orchestration_policies/ci_action/template_spec.rb — the allow_failure scan setting is applied to every injected job (false and true), and the template default is preserved when unset.
• ee/spec/lib/security/scan_execution_policies/scan_settings_spec.rb — ScanSettings#allow_failure reader.
• ee/spec/services/ci/create_pipeline_service/scan_execution_policy_spec.rb — end-to-end: a policy with scan_settings.allow_failure: false produces a dependency scanning job with allow_failure: false, and the template default (true) is preserved when the setting is absent.
• Schema spec verifying allow_failure is accepted by the security orchestration policy validator.

Follow-ups (out of scope)

• Policy editor UI toggle — delivered separately in !247084 (closed).
• DAST on-demand scans (OnDemandScanPipelineConfigurationService) use a separate code path and are not covered here.