Follow-up from "Add suffix configuration option to Pipeline execution policies"

The following discussions from !159858 (merged) should be addressed:

• @fabiopitino started a discussion: (+1 comment)

  I think all these nested blocks make the API hard to use. I would prefer if we had a simpler API like inject_jobs(jobs, target_stage: stage, on_conflict: -> {...} ) . I think we should be able to only provide the stage name rather than the stage object:

  job_injector = ::Gitlab::Ci::Pipeline::JobsInjector.new(
    pipeline: pipeline,
    declared_stages: command.yaml_processor_result.stages,
    on_conflict: -> { ... })
  
  policy.pipeline.stages.each do |policy_stage|
    job_injector.inject_jobs(jobs: policy_stage.statuses, stage: policy_stage.name) do |job|
      job.set_execution_policy_job!
      track_internal_event(...)
    end
  end

• @fabiopitino started a discussion: (+1 comment)

  This pipeline.stages << syntax I'm pretty sure it triggers a save under the hood and persists the pipeline. This is not what we want. We should instead use pipeline.stages.build.

  We also should be able to only use a target_stage_name to insert a new stage and not having to do source_stage.dup.

  position = declared_stages_positions[target_stage_name]
  pipeline.stages.build(project: project, position: position, name: target_stage_name) # ensure partition_id is propagated automatically via pipeline object
  
  # or even better by defining a new SSoT method
  class Ci::Pipeline
    def new_stage(name:, position:)
      stages.build(
        project: project,
        partition_id: partition_id,
        name: name,
        position: position)
    end
  end

  In a follow-up MR we could also replace https://gitlab.com/gitlab-org/gitlab/-/blob/0c6be823dab5538397e2b226448ebd481de3dbd8/lib/gitlab/ci/pipeline/seed/stage.rb#L52 with the new method.

• @fabiopitino started a discussion:

          def add_job!(stage:, job:)

  Since this method raises an exception.