cc-set-hostname behavior non-uniform, causes Kerberos issue

# Bug report
I have a pair of VMs running on a Proxmox host - one using Fedora 40, the other using Ubuntu Noble.
Both have similar cloud-init configurations with an FQDN specified in Proxmox's configuration:

```
root@pve-1:~# for i in 102 110; do qm cloudinit dump $i user; done
#cloud-config
hostname: sso
manage_etc_hosts: true
fqdn: sso.my.fq.dn
user: bootstrap
ssh_authorized_keys:
- ssh-rsa [snip]
chpasswd:
expire: False
users:
- default
package_upgrade: true

#cloud-config
hostname: gitlab
manage_etc_hosts: true
fqdn: gitlab.my.fq.dn
user: bootstrap
ssh_authorized_keys:
- ssh-rsa [snip]
chpasswd:
expire: False
users:
- default
package_upgrade: true
```

I was trying to debug why Kerberos (`ipa-getcert`, specifically) wasn't working on the latter of the two VMs, and it turns out it's due to how cloud-init configures the hostname.
Here's some output from cloud-init's logs:

```
2025-02-26 06:29:08,784 - helpers.py[DEBUG]: Running config-set_hostname using lock ()
2025-02-26 06:29:08,785 - cc_set_hostname.py[DEBUG]: Setting the hostname to sso.my.fq.dn (sso)
2025-02-26 06:29:08,785 - subp.py[DEBUG]: Running command ['hostnamectl', 'set-hostname', 'sso.my.fq.dn'] with allowed return codes [0] (shell=False, capture=True)
2025-02-26 06:29:08,800 - __init__.py[DEBUG]: Non-persistently setting the system hostname to sso.my.fq.dn
2025-02-26 06:29:08,800 - subp.py[DEBUG]: Running command ['hostname', 'sso.my.fq.dn'] with allowed return codes [0] (shell=False, capture=True)
2025-02-26 06:29:08,802 - atomic_helper.py[DEBUG]: Atomically writing to file /var/lib/cloud/data/set-hostname (via temporary file /var/lib/cloud/data/tmps8bh70as) - w: [644] 58 bytes/chars
2025-02-26 06:29:08,802 - handlers.py[DEBUG]: finish: init-network/config-set_hostname: SUCCESS: config-set_hostname ran successfully
```

```
2025-02-26 06:32:48,281 - helpers.py[DEBUG]: Running config-set_hostname using lock ()
2025-02-26 06:32:48,281 - cc_set_hostname.py[DEBUG]: Setting the hostname to gitlab.my.fq.dn (gitlab)
2025-02-26 06:32:48,281 - util.py[DEBUG]: Reading from /etc/hostname (quiet=False)
2025-02-26 06:32:48,281 - util.py[DEBUG]: Reading 7 bytes from /etc/hostname
2025-02-26 06:32:48,281 - util.py[DEBUG]: Writing to /etc/hostname - wb: [644] 7 bytes
2025-02-26 06:32:48,281 - distros[DEBUG]: Non-persistently setting the system hostname to gitlab
2025-02-26 06:32:48,281 - subp.py[DEBUG]: Running command ['hostname', 'gitlab'] with allowed return codes [0] (shell=False, capture=True)
2025-02-26 06:32:48,282 - atomic_helper.py[DEBUG]: Atomically writing to file /var/lib/cloud/data/set-hostname (via temporary file /var/lib/cloud/data/tmp4ym46hj8) - w: [644] 64 bytes/chars
2025-02-26 06:32:48,282 - handlers.py[DEBUG]: finish: init-network/config-set_hostname: SUCCESS: config-set_hostname ran successfully and took 0.001 seconds
```

This is confirmed in RHEL's hostname set logic (inherited by Fedora):
https://github.com/canonical/cloud-init/blob/9704ba816fb7bd7425304b864258afa7adedffae/cloudinit/distros/rhel.py#L119

vs. Debian's hostname set logic (inherited by Ubuntu):
https://github.com/canonical/cloud-init/blob/9704ba816fb7bd7425304b864258afa7adedffae/cloudinit/distros/debian.py#L160

The major difference here - on Fedora, `/etc/hostname` ends up as the FQDN. On Ubuntu, `/etc/hostname` ends up as just the single label (`gitlab`). This has a variety of follow-on issues - most notably, though, Kerberos behavior varies greatly if that file has an FQDN in it.

`hostnamectl` is a systemd component, and is available in Ubuntu. Is there any reason we're editing `/etc/hostname` directly here?
I feel like we could have some generic typing for setting hostnames via systemd's `hostnamectl` for multiple different distros. Or, at the very least, let the user select a strategy if desired.

## Steps to reproduce the problem
Boot a Fedora (40) and Ubuntu (Noble) instance, both with the same user config (specifying both `hostname` and `fqdn`).
Observe the former ends up with an FQDN in `/etc/hostname`, whereas the latter only has a base name.

## Environment details
- Cloud-init version: 24.1.4 and 24.4, respectively (but current source confirms this behavior continues to exist)
- Operating System Distribution: Fedora and Ubuntu
- Cloud provider, platform or installer type: Proxmox VE

## cloud-init logs
See above.