Consider the possibility of sym-linking vulnerabilities when projects are forked to reduce vulnerability duplication

The following discussion from !12117 (merged) should be addressed:

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

  thought: I think GitLab can also save a ton of compute with an approach like this. For example, in the context of groupcomposition analysis analysis we really only consider a handful of files during our analysis (files like Gemfile.lock). When looking at an entire repository's files these specific files don't change very often which means that we only need to consider changing vulnerabilities when advisories change, or if an analyzer gets updated. Both of these don't happen super often (advisories change once a day on average for example), so we're likely wasting some resources running analyzers to get the same results. Other groups might need access to more files, but nonetheless I think that they can take advantage of something like this to some degree.

  This becomes more enticing if you factor in that a lot of projects end up getting forked for short lived changes. If we could do some form of "symlink" for vulnerabilities for refs like these, I think we could financially save a lot too.