Support linking downstream pipelines to upstream pipelines in CI Visibility

[nikita-tkachenko-datadog]

Requirements for Contributing to this repository

• Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
• The pull request must only fix one issue at the time.
• The pull request must update the test suite to demonstrate the changed functionality.
• After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

Implements linking downstream pipelines to upstream pipelines in CI Visibility.
In order to link the two pipelines, the downstream pipeline's webhook payload should contain an additional section that has the URL and trace ID of its upstream pipeline.
The needed data are obtained from the CauseAction of the downstream's pipeline and from the BuildSpanManager in-memory cache.

The BuildSpanManager is changed from only storing info about the running jobs to also storing info about the latest N (1024 by default) finished jobs.
Storing info about the finished jobs is required because the downstream pipeline event handler needs to obtain the trace ID of the upstream pipeline (by the time this happens the upstream pipeline has already finished its execution).

The size of the cache should be in the hundreds of kilobytes.

It should be very unlikely that the upstream pipeline trace context is already removed by the time the downstream pipeline is executed, but if it happens the only logic that stops working is the one that links upstream to downstream.

Description of the Change

Alternate Designs

Possible Drawbacks

Verification Process

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

• Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
• PR title must be written as a CHANGELOG entry (see why)
• Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
• PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
• PR should not have do-not-merge/ label attached.
• If Applicable, issue must have kind/ and severity/ labels attached at least.

[drodriguezhdez]

I've dropped some comments.

[drodriguezhdez]

LGTM