Allow cross-project SPP access for PEP without checking token scope

What does this MR do and why?

Allow cross-project SPP access for PEP without checking token scope.

• It makes it easier to use PEP with multi-project pipelines (using $CI_JOB_TOKEN) by removing the need to add all projects to the job token allowlist
• It only affects pipeline execution policies
• The access is controlled by a project setting spp_repository_pipeline_access
• The access is only granted when the particular project is affected by a security policy project

References

• https://gitlab.com/gitlab-com/account-management/emea/darktrace/-/issues/61#note_2444555874
• As a workaround, customer had to switch to using pipeline triggers, but they lost the ability to see the downstream pipeline in the UI because pipeline triggers don't link the two pipelines together: #544001 (closed)

Screenshots or screen recordings

Before or with the project setting disabled	After

How to set up and validate locally

pep_access_demo

1. Create two subgroups, Group 1 and Group 2
2. In Group 2, create a PEP
3. In the SPP project created for Group 2, ensure that the setting in Settings -> General -> Visibility, project features, permissions -> Grant access to the CI/CD configurations for projects linked to this security policy project as the source for security policies. is enabled
4. In Group 2, create a project Project 2 with .gitlab-ci.yml:

   project-2-job:
     stage: test
     script: exit 0
   

5. In Group 1, create a Project 1 with .gitlab-ci.yml:

   project-1-job:
     stage: test
     script: exit 0
   
   trigger-project-2-using-job-token:
     variables:
       DOWNSTREAM_PROJECT_ID: <Replace with Project 2 ID>
     script:
       - apk add curl
       - |
         curl -vvv --request POST \
           --form token=$CI_JOB_TOKEN \
           --form ref="$CI_COMMIT_BRANCH" \
           "http://gdk.test:3000/api/v4/projects/$DOWNSTREAM_PROJECT_ID/trigger/pipeline"
   

6. Add Project 1 to Project 2 -> Settings -> CI/CD -> Job token permissions -> CI/CD job token allowlist
7. Verify that the downstream pipeline starts and is visible in the UI
8. Disable the Pipeline execution policies project setting and verify that the downstream pipeline doesn't start

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #553394 (closed)