Draft: CI: allow to enable merge trains

Context

This MR is postponed waiting for the CI infrastructure to be more stable

This MR modify the CI to allow to experiment with merge trains.

First we introduce a new type of job, that is a merge-result-job that succeeds immediately. We run this job only if the type of trigger is merge_result, this job is run when the label MR_IS_READY is present and it is mutually exclusive with the trigger manual job.

This allows to avoid a duplicated pipeline saving costs.

Second we modify the actual manual trigger to run only if the the label MR_IS_READY is not present ( that is the default for developer). This allows the developer to trigger a manual job as needed exactly as it is now. The label must be added when the MR is ready for merge.

Third we add a final job that will run the entire test array if the merge event is of type "merge_train". This will ensure to run the final pipeline before merging.

For more context refer to #6647 (closed)

Fix: #6647 (closed)

The workflow might be simplified in the future once gitlab-org/gitlab#895 (comment 1671290844) is merged

Manually testing the MR

Try adding the label MR_IS_READY and check if the manual trigger disappears from the pipeline.

Otherwise the pipeline should have a manual trigger as before.

A new pipeline will be created only upon a rebase of a push action.

Since this modification cannot be tested before enabling merge trains on tezos/tezos we tested this on a clone repository.

nomadic-labs/arvid-tezos!491 (closed) this is a pipeline for a MR with the same .gitlab-ci.yml file in this MR that has the label MR_IS_READY, it's approved, the phony pipeline was green, and for which by merging, gitlab triggered a merge_train type of pipeline. Notice that this pipeline might fail for other reasons unrelated to this change.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR