Expand E2E suite with metadata test

[lentzi90]

We lack tests for the BareMetalHost userData, networkData and metaData functionality.
This issue is for implementing such a test.

One basic thing we should check is that the content actually appears on the disk as it should.
A test could look something like this:

1. Create a secret with some metadata (userdata and networkdata can be trickier since they would change things on the host, metadata is not expected to do something on its own).
2. Provision the BMH with some image + the metadata (and perhaps some userdata and networkdata to be able to access it).
3. Access the host and look for the config drive where the metadata should be.
   It can be seen with the blkid command. Look for LABEL="config-2".
4. Mount the config drive and verify that the metadata is the same as that in the secret.

Example commands and output:

ubuntu@ubuntu-rqqzc-z9kb7:~$ sudo blkid
/dev/nvme0n1p16: LABEL="BOOT" UUID="d247b12f-2037-462d-8751-fddf35d29b81" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="261a1bdf-6568-4711-bbbb-13dff71487ee"
/dev/nvme0n1p1: LABEL="cloudimg-rootfs" UUID="ee4654d0-951c-4342-ab5e-e8f80c71b13f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b7541bc4-4492-439d-a2d5-886a7f6f202e"
/dev/nvme0n1p2: BLOCK_SIZE="2048" UUID="2025-08-20-12-53-13-00" LABEL="config-2" TYPE="iso9660" PARTUUID="be4b443c-6567-45c7-a492-7d10182e5f08"
/dev/nvme0n1p15: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="0002-E691" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="c7c38019-259f-4cea-b01d-38ddfd5f8a68"
/dev/nvme0n1p14: PARTUUID="02f0a446-fcf3-4661-bc68-259aa3392940"
ubuntu@ubuntu-rqqzc-z9kb7:~$ mkdir config
ubuntu@ubuntu-rqqzc-z9kb7:~$ sudo mount --read-only --source LABEL=config-2 --target config
ubuntu@ubuntu-rqqzc-z9kb7:~$ ls -l config/openstack/latest/
total 7
-r--r--r-- 1 root root  307 Aug 20 12:53 meta_data.json
-r--r--r-- 1 root root  754 Aug 20 12:53 network_data.json
-r--r--r-- 1 root root 5273 Aug 20 12:53 user_data

[metal3-io-bot]

This issue is currently awaiting triage.
If Metal3.io contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.