Add default_branch_image to container scanning location

What does this MR do and why?

Describe in detail what your merge request does and why.

#338877 (closed) / &5577 (closed)

This MR adds new fingerprinting logic for container scanning vulnerabilities. The location of Container Scanning security reports now contain a new field named default_branch_image, which indicates the name of the scanned image as it appears on the default branch. On non-default branches, we will use this in lieu of the image field when creating the location fingerprint. This will allow vulnerabilities to generate identical fingerprints when the image name differs between the default branch and the non-default branch.

How to set up and validate locally

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

1. Make your GDK has an EE license

2. Setup GitLab Runner and make sure a runner is registered to your group.

3. Enable Registry

4. Create a new project

5. Click New File to open the Web IDE

6. Create a .gitlab-ci.yml with the following content:

   include:
   - template: Jobs/Build.gitlab-ci.yml
   - template: Security/Container-Scanning.gitlab-ci.yml
   
   build:
     services:
       - name: 'docker:20.10.6-dind'
         command: ['--tls=false', '--host=tcp://0.0.0.0:2375', '--insecure-registry=gdk.local:5000']

7. Create a Dockerfile with the following content:

   FROM debian:10

8. Commit your changes to main

9. Go to CI/CD -> Pipelines and run a new pipeline on main

10. Create a new branch and add any new commit (i.e. Add README.md).

11. Open a merge request against main.

12. Run a pipeline on the new branch if it does not start automatically.

13. Check the merge request once the pipeline has finished and observe that it adds 100+ vulnerabilities despite no changes:

    

14. Enable the feature flag:

    Feature.enable(:improved_container_scan_matching)

15. Go to CI/CD -> Pipelines and run a new pipeline on the non-default branch.

16. Refresh the merge request page when the pipeline completes and observe that no new vulnerabilities are added:

    

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.