Fix upstream pipeline status when strategy dependent

What does this MR do?

Problem

Related to #212435 (closed)

When a pipeline triggers another pipeline, the upstream pipeline can have an option of depending on the downstream pipeline status with strategy: depend. Let's say the downstream pipeline has a flaky job, at first it fails, so the bridge job between the upstream and the downstream pipelines fails. But then, the user can retry the job or the pipeline, and it can succeed. Then we need to update the bridge and the upstream pipeline. This scenario can also happen in the opposite way (first succeeds, retries, then fails).

This MR fixes that problem. However, it does not cover "Mirroring status from upstream pipeline" feature (comment: #212435 (comment 410067521)).

Solution

When a pipeline completes, it enqueues Ci::PipelineBridgeStatusWorker if an upstream pipeline waits for its result (pipeline.bridge_waiting?). That worker makes the bridge job inherit the status from the downstream pipeline (pipeline.source_bridge.inherit_status_from_downstream!(pipeline)).

Before this fix, the bridge job is in failed state, and it can not be converted to success state directly. That's why we keep getting these errors: https://sentry.gitlab.net/gitlab/gitlabcom/?query=InvalidTransitionError (p.s. not sure about it)

In this MR, whenever a job is retried or a pipeline is retried, its bridge job is converted to pending state so that it can be converted to failed or success in a right way.

Screenshots

The downstream pipeline fails first

Then the failed job is retried

Then the downstream pipeline succeeds

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team