Iterate on `Security::JobsFinder`

What exists now

JobsFinder takes a pipeline and returns the Ci::Build for any security job in it.

Issues

Identifying the job type

It's not easy to determine what type of security job a Ci::Build represents.

If :ci_build_metadata_config is enabled, it looks like:

build.metadata.config_options[:artifacts][:reports].first.first # "sast", "dast", etc.

If that feature is not enabled, we have:

build.options[:artifacts][:reports].first.key # "sast", "dast", etc.

Both of these methods are unwieldy.

N+1 queries

When :ci_build_metadata_config is not enabled, JobsFinder returns a Ruby array. This prevents us from using it for features like #13298 (closed) without creating an N+1 situation (where N is the number of projects).

Other considerations

In #13638 (closed), we associate a name (for example, "Static Application Security Testing (SAST)") and description ("Analyze your source code for known vulnerabilities") with the configuration for a security job. Where should that information live?

Proposed solutions

Represent each security job type as a Ruby object

When JobsFinder fetches each security job, pass the Ci::Build into an object (a model? a presenter?) that represents the type of security job. This object can encapsulate knowledge of what job type it is as well as other information, like the name and description needed on the configuration page.

Removing the N+1 issue

TBD

Open questions

1. Where should information specific to a security job type live?
2. How can we avoid creating an N+1 query if we use JobsFinder to support features on the group and instance security dashboards?