Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Commit  d0487486 "lava: Reduce redundancy in the profile
definitions" introduced a change that ended up causing issues with the
AUM tests, so let's go back to the previous state.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Use YAML anchors and extensions to avoid repeating the same contents over
and over.

This commit does not introduce any change in the generated job
definitions, except for the case below, which is harmless:

    apertis_ostree-minimal-armhf-uboot
    -      commands: ['reset']
    +      commands: ['run bootcmd_mmc0']

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

It turns out that LAVA really wants strings for the metadata entries and
didn't like nesting a dictionary there.

For this reason it was failing to submit jobs with this error:

    Submitting job group-apparmor-tpl.yaml: <Fault 400: "Problem with submitted job data: expected str for dictionary value @ data['metadata']['source']">

Unfortunately our custom `lava-submit.py` was silently eating the error
so the pipeline was marked as successful.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

The `source:wip:` metadata can be used to indicate that a submission
came from a work-in-progress branch and that it should not be accounted
when checking the overall health of the projects.

For instance, the Phabricator bridge can use this information to avoid
opening bug tasks for failures coming from a WIP branch.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Introduce the variables below:

* source_ref
* source_commit
* source_pipeline
* source_job

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

In preparation for adding more metadata, make the `source` entry an
object rather than a single string.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Default to `null` rather than hardconding a possibly misleading source.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Port the below MR from apertis-tests, which got landed while we were
moving the templates around:
https://gitlab.apertis.org/pkg/development/apertis-tests/-/merge_requests/190



This reverts the introduction of the OTA update tests on the internal
minimal armhf since their behavior isn't stable and there is no value to
test AUM on this platform.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Keeping the LAVA job templates in `apertis-tests` has many problems.

Since `apertis-tests` is also a package, updates for stable releases
should go through `-updates` branches, but that plays badly with the
image building recipes as they only pull from the the main branch.

There's also an annoying disconnect about what the testcases here say
about where they should be run, and the actual groups used by the
templates.

By moving the LAVA templates here we can later improve them by
generating the groups based on the actual data in the testcases.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>