Implementing device_aliases as described in docs

[mal]

Proposed Commit Message

Implement missing device_aliases feature

The device_aliases key has been documented as part of disk_setup for
years, however the feature was never implemented. This implements the
feature as documented allowing usercfg (rather than dsconfig) to create
a mapping of device names.

This is not to be confused with disk_aliases, a very similar map but
existing solely for use by datasources.

LP: #1867532

Additional Context

As summarised by @blackboxsw during cloud-init bi-weekly office-hours meeting 2021-07-13.

Simply, for "migration reasons" you want to be able to simply support the documented device_aliases config dict as variable replacement values across both cc_disk_setup and cc_mount config modules to avoid repetition in user-data definitions because in your case you generally know what those alias to device path mappings will be on the "new" system.

The more common of the cases here is the avoidance of repetition and improved readability of the config, especially when running to eight plus disks. This is probably best considered as the primary motivator here, however below is an attempt to clarify one of the nebulous "migration reasons" with a fairly contrived hypothetical inspired by a real-world case I'm currently dealing with:

The headline summary of my real-world case reads something like: Reattach disks to a stopped cloud instance as different devices, without cloud-init getting upset and trying to treat them as the devices originally at those locations.

1. Boot new VM with three data disks, cloud-init config in userdata, all fairly normal.
2. Requirement to switch around disks. Contrived hypothetical: sda -> sdb, sdb -> sdc, sdc -> sda.
3. Add device_aliases describing this remapping to /etc/cloud.
4. Stop instance.
5. Detach/reattach disks as desired.
6. Start instance back up.
7. Boot behaves itself after resolving aliases.

Since the natural response is to ask why this couldn't be done using a new VM with correct configuration in userdata, it's worth addressing here. That would be the preferred option in many cases, however in this one data that must be persisted is written to the OS disk, which cannot be mounted on a separate VM. Because of course it was. 🤦

Test Steps

• Manual testing on a dev server
• Expansion of sanitize_devname tests

Checklist:

• My code follows the process laid out in the documentation
• I have updated or added any unit tests accordingly - cc_mount only, cc_disk_setup is DI which doesn't seem trivially testable.
• I have updated or added any documentation accordingly - Pre-existing

[TheRealFalcon]

Thanks for the contribution! Your changes look good. I am also pushing an integration test to your branch for this behavior.