Add API endpoint for pipeline bridge jobs

Related to #207226 (closed)

Problem statement

When using GET /pipelines/:id/jobs, the response does not list any bridge jobs although the were created successfully.

Analysis

From #207226 (comment 291511965):

GET https://gitlab.example.com/api/v4/projects/123/pipelines/12345/jobs: missing job2 and job3 and no reference to the created child-pipelines

• on missing jobs2 and jobs3, this occurs because those are "trigger" (also called "bridge") jobs and when we serialized jobs for a pipeline we only collect "normal" jobs (those that are executed by the Runner). I think this predates the notion of "trigger" jobs. Instead of pipeline.builds we should use pipeline.processables to include everything. I'm not sure this classifies as ~bug if it was a miss or a feature if we had a reason for only returning runnable jobs.
• on not serializing created child-pipelines: we should definitely render them and perhaps even inside the "trigger" jobs (currently missed) so it will be clear which job triggered which child pipeline.

☝ this could probably be an issue on its own and it's more complicated: for /pipelines/:id/jobs we are using specific preloads and serializer for Ci::Build. This won't directly apply to Ci::Bridge jobs. We could create a new API endpoint GET /pipelines/:id/bridges that instead returns only bridge jobs. This means we could serialize them differently than Ci::Build and even include a reference to the downstream pipeline.

Otherwise a more complex solution would be to reuse GET /pipelines/:id/jobs and return a list of processables that can be either Ci::Build or Ci::Bridge. This is like returning polymorphic associations which has a set of complications (e.g. preloading :job_artifacts won't work on Ci::Processable). I'm not sure we do that or discourage it. - cc @ayufan ?

Proposal

We could create a new API endpoint GET /pipelines/:id/bridges that instead returns only bridge jobs. This means we could serialize them differently than Ci::Build and even include a reference to the downstream pipeline.

• pros: very easy to implement
• cons: clients will need to call 2 endpoints to get all the jobs in a pipeline

old alternative proposal:

Including bridge jobs in the existing API endpoint is preferable although a bit more complex.

1. Because we can't simply use pipeline.processables as we are preloading specific associations from Ci::Build, we may need to do it differently. Maybe UNION both pipeline.builds and pipeline.bridges (to be created) each with their own preloaded associations
2. in Entities::Job serializer we expose job specific attributes (e.g. artifacts) and bridge specific attributes (e.g. downstream pipelines) based on the type

• pros: clients will get all jobs with a single API call, much like the UI
• cons: complex to implement on many fronts (query, serializers, schema)