Draft: Component Filter on Project level Dependencies List

What does this MR do and why?

Introduces a component filter to the project-level dependencies list.

This is a mammoth MR. It will be split into thinner reviewable chunks, and is only an all-in-one MR as I've been exploring FE & BE simultaneously as learning exercise. It is not unit tested at all yet (in fact there are lots of broken tests) and those will be fixed down the line.

It's shared just now for early review on feasibility and correctness of implementation. I took a swing at this to learn about how we approach development, so I'm very much looking for feedback to accelerate my learning, and hopefully land this change!

How does this work?

1. The /<project>/dependencies/dependency_names endpoint returns a list of (SbomOccurrence ID, Component Name) pairs. This uses the existing Sbom::Occurrence.by_project_ids function and renders the result using a new Grape entity.
2. The frontend calls this endpoint when the Component search filter is requested. These are then mapped through to the search drop down - a lot of this work was already done, my contribution here is mainly plumbing.
3. We use the SbomOccurrence ID of each component to do the search. /<project>/dependencies.json?occurrence_id[]=1&occurrence_id[]=2
   1. The ID lookup is an extension of the existing search. The existing search starts with the Sbom Occurrences from the latest successful pipeline, meaning if a bad actor tries to find occurrences from a different project (maybe one that isn't theirs), no additional results will be returned.

I've also wired in the License filter here as it was an easy copy-paste from the group level.

Questions:

• I am getting wildly different query times on cold-cache when running select id, component_name from sbom_occurrences where project_id = 278964 (278964 is gitlab, which I'm using as a test for "project with loads of dependencies"). Exact same buffer hits and reads, but one takes 2.545 seconds and one takes 91.247 milliseconds. Why is this so variable?! This SQL is the most raw version of what we need for the dependency_names endpoint - I believe the version in the MR is a select * from , happy to take advice on what's best here.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screen Recording 2024-07-21 at 19.37.16.2.mov

How to set up and validate locally

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