Previously we integrated all projects into the manifest, even those that
belonged to a different manifest branch. That led to all manifests
having the same project revisions, even if they should be different due
to different intgrated project branches.

Save a list of integration sources for each manifest branch separately
now, so that we can check which project belongs to which manifest branch
later.

TypeError: 'NoneType' object is not subscriptable
Example:
https://git.seco.com/seco-ne/yocto/infrastructure/ci-test/minimal-manifest/-/jobs/127610

When we're integrating a single branch into a single manifest branch,
there is no need to run the intgeration pipeline for all configured
integrations, but only for those that match the target branch of the
current merge request.

This should catch an error where during a gitlab-ci merge process the
wrong foo branch is integrated into the manifest, which happened in
Yocto.

We need to pass the correct target branch to the merge request creation
instead of using the project's default branch.

Otherwise no pipeline is created at all in these merge requests, which
prevents the MR from being merged.

We have deleted the original project due to git corruption. Replace with
the new project's ID.

Instead of getting the projects from the manifest file, search them via
their INTEGRATION variable.

Improve log messages on this occasion: print URL instead of just IDs.

Add different integration jobs for different manifest branches. The
merge stage only has one job for each manifest, though, because
otherwise we cannot guarantee a consistent state for all branches.

Extend the deploy script for this purpose, so that it can deploy to
multiple manifest branches at once.

We were passing the complete TemporaryDirectory object to the repo clone
function instead of just the path string, resulting in the repo being
cloned into a local dir "<TemporaryDirectory '/tmp/tmphwakypf8'>".

Fix this to actually use the generated temp dir.

This change makes it necessary to keep the TemporaryDirectory object
reference until we don't need the directory anymore, otherwise it will
be removed immediately.

Get targets dynamically using the INTEGRATION variable instead.

This makes it possible to retrigger jobs that are not part of the
given pipeline but in any nested child pipeline of it.

MANIFEST_PROJECT, MASTER_BRANCH_MANIFEST, MASTER_BRANCH_PROJECT

Branch can be implicitly determined via the repo.

Using new function raise_if_error() of GitPython 3.1.25:
https://gitpython.readthedocs.io/en/stable/tutorial.html#handling-remotes

This makes it possible to integrate a project branch into different
branches of the same manifest project.

Evaluate the INTEGRATION variable to determine target project and branch
for integration instead of using the hard-coded variables. For now this
works only for a single integration per target project because the
integration branch name does not include the target branch and hence
would be identical when trying to integrate into multiple branches of
the same project.

We have created tags in our poky repo which are needed by repo, e.g.
https://git.seco.com/seco-ne/3rd-party/yocto/poky/-/tags/seconorth%2Fkirkstone-4.0.0

Do not explicitly exclude tags in order to fetch them.

Especially when downloading the SDK the deploy takes longer than 10min.

When the dump_install_command script is executed in the SDK build step
an error occurs because the fng-install script/vars are not available.

Adds scripts for mark down generation.
Adds scripts for lava test result queries.
Adds script to generate a mark down report from this data
Call script from submit_test to generate a report directly
after the testrun.

The images from the build job can be directly installed from gitlab.
To achive this some changes in the complete pipeline have been needed.

1. The variables used in the build job, like CI_PARAM_IMAGE, ... and
   related variables like BUILDPATH are only valid in the build job now.
2. The build job writes every variable needed in a follow up job into
   build.env. This also includes the url to the fng-install.sh of the
   final image.
3. The build.env file is used as dotenv artifact, as well as normal
   file artifact.
   The dotenv make the written variables automatically available in
   follow up jobs, that are using the aritfacts, like the deploy job.
   The normal file artifact is available via artifact download.
   (I did't found a way to download the dotenv file instead)
4. Some scripts have been added:
   - Find a job inside the pipeline by name, as the id is not known in
     advance.
   - Download all artifacts or one file of the artifacts from a given
     job
   - Download one file of the latest job by name
5. The scripts are used to download the build.env into the test job
   (where not artifacts are needed anymore)
6. The script is sourced and all variables are available inside the
   script.

Additionally this adds a fake build job to the ci-test pipeline, that
copies an image from srv73 and stores it as artifact in a way that a
test-job can run on it, like in the normal yocto pipeline.

This shares YAML code for the following procedures:
- Build environment
- Source code checkout via repo
- SSH key and known hosts setup
- LAVA test submission
- Docker check if build folder is empty