Draft: Add security report time window to policy_tuning

What does this MR do and why?

This MR adds a time window configuration in the MR approval policy that allows users to specify a time frame for comparing security results. This will enable comparisons against the latest pipeline with security reports created within a specified time range, rather than always waiting for the most recent baseline run to complete.

Target branch pipeline selection

The current logic of selecting a target branch pipeline is to look for pipelines with the required security reports in preferred SHA order:

• diff_head_pipeline.target_sha
• diff_base_sha
• diff_start_sha

But if no pipeline is found for those SHAs with security report, the approval policy comparison fails due to missing baseline to compare.

The new logic updates it by using the time window configuration to query the pipelines in a time range so that we are guaranteed to get a pipeline with security report for older SHA.

Flow Diagram

flowchart TD
    A[target_pipeline_for_approval_policy] --> B[Query comparison_pipeline for target branch sha]
    B --> F{Found comparison_pipeline?}
    
    F -->|Yes| G[Return comparison_pipeline]
    F -->|No| H{Feature flag enabled AND time_window present?}
    
    H -->|Yes| I[Find pipeline within time window]
    I --> J{Found pipeline with time window?}
    J -->|Yes| K[Return time window pipeline]
    J -->|No| L[Return latest_pipeline_for_target_branch]
    
    H -->|No| L[Return latest_pipeline_for_target_branch]
    
    G --> N[End]
    K --> N
    L --> N

Pipeline selection within time window

graph TB
    subgraph "Time Window: 12:00 - 14:00 (2 hours ago → now)"
        direction LR
        TW1[12:00<br/>Window Start]
        TW2[14:00<br/>Current Time]
    end
    
    subgraph "Pipeline Analysis"
        direction TB
        PA[Pipeline A<br/>Created: 11:00<br/>Status: ❌ Outside Window]
        PB[Pipeline B<br/>Created: 12:30<br/>Status: ✅ Valid]
        PC[Pipeline C<br/>Created: 13:00<br/>Status: ✅ Valid]
        PD[Pipeline D<br/>Created: 13:30<br/>Status: ✅ Valid]
        PE[Pipeline E<br/>Created: 14:00<br/>Status: 🔄 Comparison Pipeline<br/>Used in created_before_id filter]
    end
    
    subgraph "Selection Logic"
        SL1[Filter by time window<br/>Valid candidates: B, C, D]
        SL2[Check report availability<br/>B, C, D have required reports]
        SL3[Filter created_before_id: E.id<br/>Only B, C, D remain]
        SL4[Order by ID descending<br/>D → C → B]
        SL5[Return Pipeline D]
    end
    
    TW1 -.-> PB
    TW2 -.-> PE
    
    PB --> SL1
    PC --> SL1
    PD --> SL1
    PE -.->|"created_before_id filter"| SL3
    
    style TW1 fill:#e3f2fd
    style TW2 fill:#e3f2fd
    style PB fill:#c8e6c9
    style PC fill:#c8e6c9
    style PD fill:#c8e6c9
    style PA fill:#ffebee
    style PE fill:#fff3e0

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

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.

Addresses #525509 (closed)