Block premature merges on ref-based pipeline creation (FF)

This replaces !256821 (merged), which GitLab marked as merged by mistake: during a stack reorder, the branch it targeted was force-pushed on top of its commits. Nothing was merged into master or reinstate-232296-a-reader. Earlier review history is on !256821 (merged).

What does this MR do and why?

This is the reader MR in the stack that reinstates !232296 (merged). It follows the scaffolding MR !256819 (merged), which is merged and deployed. It adds the track_ref_pipeline_creation flag. It reads ref requests that the writer MR (!256820) writes; until the writer ships, nothing writes them, so the new check always returns false.

MergeRequest#pipeline_creating? now also returns true when a pipeline is being created for the source ref, via a new pipeline_creating_for_source_ref?, gated on track_ref_pipeline_creation. This closes the branch-pipeline race: the CI mergeability check now blocks a merge while a ref pipeline is still being created, not only while a merge-request pipeline is being created. Alongside that mergeability change in merge_request.rb, this MR also adds the ref-lookup methods it needs on Ci::PipelineCreation::Requests: for_ref, pipeline_creating_for_ref?, and the key helpers ref_key and REF_REDIS_KEY.

This MR is safe to merge while the flag is off. To back out the merge blocking, turn the flag off.

Feature flag

track_ref_pipeline_creation (type gitlab_com_derisk, default_enabled: false), milestone 19.5, introduced_by_url points to this MR (!258481 (merged)). The rollout issue and feature issue already exist and are reused, not recreated.

No UI changes.

References

• Reinstated MR: !232296 (merged)
• Revert MR: !239194 (merged)
• Incident: gitlab-com/gl-infra/production#22243 (closed)
• Reinstatement issue: gitlab-com/gl-infra/production-engineering#29150
• Feature issue: #595420
• Rollout issue: #597220
• Stack: scaffolding (!256819 (merged), merged), reader (this MR, !258481 (merged)), writer (feature-flagged, !256820)