cexec: grab the mountpoints using the metadata service if requested.

[mgrzybek]

Description

At the moment, cexec can only mount one block device to create the chroot environment. Moreover, the target block device needs to be provided.
This PR allows cexec to query the metadata service in order to mount the whole filesystems declared in the Hradware object.

How Has This Been Tested?

Both retro-compatibility and the new feature have been tested.
I used this template:

---
apiVersion: tinkerbell.org/v1alpha1
kind: Template
metadata:
  name: cexec-testing
  namespace: tinkerbell-system
spec:
  data: |
    version: '0.1'
    name: cexec_testing
    global_timeout: 6000
    tasks:
    - name: "Partitioning and checking"
      worker: "{{.machine_mac}}"
      volumes:
       - /sys:/sys
       - /dev:/dev
       - /dev/console:/dev/console
       - /lib/firmware:/lib/firmware:ro
      actions:
      - name: "disk-wipe-partition"
        image: registry.ring0:5000/tinkerbell/actions/rootio:latest
        timeout: 90
        command: ["partition"]
        environment:
          MIRROR_HOST: 192.168.3.5
          METADATA_SERVICE_PORT: 7172
      - name: "format"
        image: registry.ring0:5000/tinkerbell/actions/rootio:latest
        timeout: 90
        command: ["format"]
        environment:
          MIRROR_HOST: 192.168.3.5
          METADATA_SERVICE_PORT: 7172
      - name: "mount"
        image: registry.ring0:5000/tinkerbell/actions/rootio:latest
        timeout: 90
        command: ["mount"]
        environment:
          MIRROR_HOST: 192.168.3.5
          METADATA_SERVICE_PORT: 7172

      - name: Use cexec to check the mount points using the metadata
        image: registry.ring0:5000/tinkerbell/actions/cexec:dev
        timeout: 3601
        environment:
          MIRROR_HOST: 192.168.3.5
          METADATA_SERVICE_PORT: 7172
          CHROOT: y
          DEFAULT_INTERPRETER: "/bin/bash -c"
          CMD_LINE: df -h

      - name: Use cexec to check the mount points using the env
        image: registry.ring0:5000/tinkerbell/actions/cexec:dev
        timeout: 3601
        environment:
          BLOCK_DEVICE: /dev/sda3
          FS_TYPE: ext4
          CHROOT: y
          DEFAULT_INTERPRETER: "/bin/bash -c"
          CMD_LINE: df -h
---
apiVersion: tinkerbell.org/v1alpha1
kind: Workflow
metadata:
  name: cexec-testing
  namespace: tinkerbell-system
spec:
 templateRef: cexec-testing
 hardwareRef: node-1
 hardwareMap:
   machine_mac: 10:66:6a:07:8d:01
---
apiVersion: tinkerbell.org/v1alpha1
kind: Hardware
metadata:
  name: node-1
  namespace: tinkerbell-system
spec:
  disks:
    - device: /dev/sda
  interfaces:
    - dhcp:
        arch: x86_64
        hostname: node-1.ring0
        ip:
          address: 192.168.3.150
          netmask: 255.255.255.0
        lease_time: 86400
        mac: 10:66:6a:07:8d:01
        name_servers:
          - 192.168.3.7
        uefi: true
      netboot:
        allowPXE: true
        allowWorkflow: true
  metadata:
    instance:
      crypted_root_password:
      hostname: node-1
      operating_system:
        distro: ubuntu
        image_tag: noble
        os_slug: ubuntu-noble
        slug: noble
        version: "24.04"
      ssh_keys:
      storage:
        disks:
        - wipe_table: true
          device: /dev/sda
          partitions:
          - label: EFI
            number: 1
            size: 1228800
          - label: SWAP
            number: 2
            size: 1228800
          - label: ROOTFS
            number: 3
            size: 0
        filesystems:
        - mount:
            create:
              options:
            device: /dev/sda2
            format: swap
            point:
        - mount:
            create:
              options:
            device: /dev/sda3
            format: ext4
            point: "/"
        - mount:
            create:
              options:
            device: /dev/sda1
            format: vfat
            point: "/boot"
  userData:

How are existing users impacted? What migration steps/scripts do we need?

There is no migration to plan. The former behaviour is still possible.
In order to use the new feature, the README.md has been updated too.

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade