iso9660 not supported on 4k devices for config drives

A downstream reporter has attempted to use ironic to deploy a running OS with shiny new 4k IO devices.

The deployment of the OS image works just fine. The issue is the creation and write-out of the configuration drive.

Specifically, when they attempt to boot a machine, they get the following kernel error log attempting to access the iso9660 filesystem from a 4k device.

[ 82.511907] isofs_fill_super: bread failed, dev=sda2, iso_blknum=17, block=-2147483648

cloud-init, when it is running logs the following:

2023-07-11 05:42:14,601 - subp.py[DEBUG]: Running command ['mount', '-o', 'ro', '-t', 'auto', '/dev/sda2', '/run/cloud-init/tmp/tmpkf7q2n3s'] with allowed return codes [0] (shell=False, capture=True)
2023-07-11 05:42:14,621 - util.py[DEBUG]: Failed mount of '/dev/sda2' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro', '-t', 'auto', '/dev/sda2', '/run/cloud-init/tmp/tmpkf7q2n3s']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: /run/cloud-init/tmp/tmpkf7q2n3s: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error.
2023-07-11 05:42:14,621 - __init__.py[DEBUG]: Datasource DataSourceConfigDrive [net,ver=None][source=None] not updated for events: New instance first boot
2023-07-11 05:42:14,622 - handlers.py[DEBUG]: finish: init-local/search-ConfigDrive: SUCCESS: no local data found from DataSourceConfigDrive

Examining the cloud-init source code[0], it appears the rules constraint has been:

* an iso9660 or vfat filesystem

OR

* A file system with a config-2/CONFIG-2 label.

That basic logic[0] has been present since 2014.

The original strict constraint seems largely rooted in nova, which also appears like it had deprecated the vfat option. And, it is sort of a reasonable constraint in the virtualized context.

So I think the option forward is to update ironic-python-agent to handle this gracefully.

Two options:
1) Attempt to remount the device, and if fails, reformat, extract, and copy the config content to the new filesystem. This can inherently help create a security issue, so we might need to make the filesystem configurable.

2) Identify the device is a 4k IO device (how?!?) and then base the steps on that.

One issue to consider is if someone starts adding a lot of content into their configuration drive, since a larger block size could mean many smaller files won't be able to fit in the same space potentially. But... that shouldn't be an issue for the 99% of operators out there using configuration drives, and those doing embedded contents can likely just easily ship a different filesystem anyhow.

[0]: https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceConfigDrive.py#L278-L299