Spike: Prepare PoC and document limitations for Security Policy Support for Compliance Pipelines

Time-box: 5 days

Why are we doing this work

In the scope of this Spike, we would like to know what we need to do to move forward with Pipeline Execution Action (Custom CI YAML Suppo... (&7312 - closed) and prepare changes that will allow us to work on this incrementally.

Additionally, we should check the list provided at Evaluate redesign of Compliance Framework pipel... (#416104 - closed) to see how we can solve these problems with the new design of Security Policy Support for Compliance Pipelines.

As an expected result of this Spike, we would like to get the following:

MR prepared for review with changes behind feature flag with Proof of Concept of the initial version of Security Policy Support for Compliance Pipelines (you can use Add support for Compliance Pipelines in Securit... (!126457 - merged) as a reference or starting point): our goal is to deliver it behind feature flag to share with UX/PM and potentially some customers to align requirements better,
New implementation issues created with Implementation Plan added to Pipeline Execution Action (Custom CI YAML Suppo... (&7312 - closed),

we could follow the same mechanism as we currently have for Scan Execution Policies, adding a suffix with policy index to all jobs provided in the config from the ci_configuration_path/ci_configuration field - this will solve potential problems with merging multiple configs as we will eliminate conflicts,
we need to find a way to show errors to users that we were not able to fetch/merge configuration,
we need to consider security implications: when the author of the last MR with a change to the policy does not have access to the project provided in ci_configuration_path we should not fetch that configuration and we should limit projects that you can fetch ci_configuration_path from to only these projects that share ancestor with project where policy is applied,
for this PoC we should focus on backend changes only,