Do not submit running pipelines data until accurate start time is known

[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?

Updates the code to not submit pipeline trace if its accurate start time is not known.
This is needed because the backend relies on start time being constant (otherwise the finished pipeline record will not converge with its running pipeline record).

The accurate start time for a pipeline (WorkflowRun) is only known once the first step starts executing.
Everything before that counts as queued time: for example, a pipeline might be waiting for available executor.

Previous version of the code simply avoided sending pipeline data inside the #onStarted() callback (since the callback is executed before the available executor check).
This is not always sufficient: other callbacks that happen before the first step execution (such as the SCM callback for checking out a shared library) need to be excluded as well.

The new approach is more robust, as it checks that the pipeline queue time has been calculated (which only happens once the pipeline leaves the buildable queue).

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.