meta-lxatac-software: containers: pass through /var/cache/labgrid

[a3f]

Labgrid's ManagedFile class handles synchronisation of files to remote hosts.
When a path is not accessible on the TAC, it will be transferred into
/var/cache/labgrid and then that path is passed to locally installed tools.

To allow transparently using these paths from within a container, add it
to the volumes passed through when running container-start.

This was tested as follows:

• On the development host, create rkdeveloptool-rk3399pro.yaml with:

    targets:
      main:
        resources:
          RemotePlace:
            name: !template '$LG_PLACE'
        drivers:
          RKUSBDriver:
            usb_loader: usb_loader
    tools:
      rk-usb-loader: /bin/rkdeveloptool
    images:
      usb_loader: /home/a3f/Downloads/rk3399pro_loader_v1.20.115.bin

• On the TAC, install rkdeveloptool inside the Debian container

• On the TAC, add /bin/rkdeveloptool with:

    #!/bin/sh

    podman start debian >/dev/null
    podman exec debian rkdeveloptool "$@"
    podman stop -i -t 0 debian >/dev/null

• On the TAC, add into Labgrid System config for each USB port:

    RKUSBLoader:
      match:
        'ID_PATH': '{{sysfs}}'

This allowed using of labgrid-client bootstrap to call rkdeveloptool on
the remote target without having to have a recipe for rkdeveloptool.

[a3f]

Eventually, we'll want a rkdeveloptool bitbake recipe, but given that Debian packages it and the OE layer index doesn't know about it, I took the easy route for now.

[hnez]

I am not a huge fan of this PR, to be honest. It feels like a hack.

I've opened #213, which should solve the underlying problem of not having rkdeveloptool on the TAC.

[a3f]

Ye, the testing how-to is a hack. I still think it makes the container more useful in general.

[jluebbe]

I find adding tools for labgrid via the container a valuable use-case. For that, the relevant locations in the FS should be accessible to the container.