Prevent DNS resolver host aliases from moving to the wrong host

[djlongy]

What this fixes

This fixes a DNS resolver bug where host aliases can end up attached to the wrong host after a playbook reorders the hosts list.

In plain terms: if one host has aliases and another does not, changing the order of those hosts can cause the alias-less host to incorrectly inherit the other host's aliases in config.xml.

Why this is a problem

That means the saved pfSense DNS resolver configuration no longer matches the playbook input:

• aliases can appear under the wrong host
• DNS records can be applied to the wrong entry
• service names can resolve to the wrong destination
• subsequent runs can look inconsistent or confusing to operators
• automation becomes unsafe because a harmless reorder can change resolver behavior

In practice, this can break anything depending on those internal DNS names being correct, including:

• reverse proxies routing traffic to the expected backend
• Kubernetes ingress controllers and ingress proxies resolving upstream services
• internal service-to-service traffic that depends on pfSense DNS overrides

How it breaks

The module updates XML list entries by position. When a host that previously had aliases is replaced in that same XML position by a host with no aliases, the old nested alias entries are left behind instead of being cleared first.

So the host data changes, but the old alias children remain attached to that XML node.

Why this fix works

Before writing a plain scalar value into an XML element, this patch now removes any leftover child elements from the previous value.

That ensures a host with no aliases stays a host with no aliases, even if the host order changes.

Included in this PR

• a focused fix in plugins/module_utils/pfsense.py
• a regression test covering host reordering with aliases
• a fixture that reproduces the bad before-fix XML shape

Validation

• targeted unit test for pfsense_dns_resolver passes
• regression test confirms aliases stay with the correct host after reorder
• branch rebased cleanly onto current master

[opoplawski]

I haven't had a chance to look at this yet, but could you add a changelog fragment? Also, I'm not sure why the tests are not running for this PR.

[djlongy]

No problem, I've added a changelog fragment as requested :)