Add tooltip for policy approval

What does this MR do and why?

Add tooltip for policy approval

• explain why the approval is necessary
• add graphql endpoint property

Changelog: added

EE: true

Design

(from #420335 (comment 1505704761))

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Scenario	Screenshot
Single Rule
Multiple Rules
Multiple approvals

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Upload a GitLab Ultimate license
2. Navigate to a project with protected branches => Secure => Policies => New policy => Scan Result Policy
3. Create a policy that has a rule that triggers on every merge request (the yaml below could be copy/pasted in). Click the Configure with merge request button, merge the resulting MR, navigate back to the project

yaml

type: scan_result_policy
name: Prevent Critical/High Vulnerabilities
description: This is to prevent Critical/High Vulnerabilities from getting merged
enabled: true
rules:
  - type: any_merge_request
    commits: any
    branch_type: protected
actions:
  - type: require_approval
    approvals_required: 2
    role_approvers:
      - maintainer
      - developer
      - owner

4. Create an MR against a protected branch
5. View MR with pipeline run
6. View approvals
7. Verify there is one rule
8. Hover over the one needing approval and verify tooltip appears
9. If you want to create more rules, use the below summary to add another rule

Security Scan Instructions

1. Upload a GitLab Ultimate license
2. Clone a project that has dependency scanning already enabled or create one
3. Navigate to the project => Secure => Policies => New policy => Scan Result Policy => yaml mode
4. Create a policy that triggers dependency scanning on every pipeline

yaml

type: scan_result_policy
name: Enforce Dependency Scanning in every protected branch pipeline
description: This policy enforces pipeline configuration to have a job with Dependency Scanning scans
enabled: true
actions:
- scan: dependency_scanning
  tags: []
rules:
- type: pipeline
  branch_type: protected

5. Use the yaml below to create a policy with two rules: one a scan finding rule that will not be triggered and one a license finding rule that we will trigger

yaml

type: scan_result_policy
name: Prevent a lot of critical vulnerabilities AND all license changes
description: Two rules in one policy
enabled: true
actions:
- type: require_approval
  approvals_required: 1
  role_approvers:
  - developer
  - maintainer
  - owner
rules:
- type: scan_finding
  scanners:
  - api_fuzzing
  vulnerabilities_allowed: 100
  severity_levels:
  - critical
  vulnerability_states: []
  branch_type: protected
- type: license_finding
  match_on_inclusion: false
  license_types:
  - MIT License
  license_states:
  - newly_detected
  - detected
  branch_type: protected
approval_settings:
  block_protected_branch_modification:
    enabled: false

6. On the project, change the LICENSE to be non MIT
7. View MR with pipeline run
8. View approvals
9. Verify there are two rules of the same name; one not needing approval and one needing approval
10. Hover over the one needing approval and verify tooltip appears

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #420335 (closed)