What does this implement/fix?

Use hostsdir for custom.list to avoid cache flushing on changes. When adding a domain into the empty list, the expected output in pihole.log is:

Nov 13 09:56:00 dnsmasq[1761111]: inotify: /etc/pihole/hosts/custom.list new or modified
Nov 13 09:56:00 dnsmasq[1761111]: read /etc/pihole/hosts/custom.list - 2 names

when removing it again:

Nov 13 09:56:34 dnsmasq[1761111]: inotify: /etc/pihole/hosts/custom.list new or modified
Nov 13 09:56:34 dnsmasq[1761111]: inotify: flushed 2 names read from /etc/pihole/hosts/custom.list
Nov 13 09:56:34 dnsmasq[1761111]: read /etc/pihole/hosts/custom.list - 0 names

The DNS cache stays intact across these events.

It is expected to see two instead of one domain being added above if dns.expandHosts is true as each HOSTS entry actually adds two domains: test and test.lan (assuming you added test and lan is your dhcp/dns.domain).

On a fresh migration, FTL reads custom.list and copies it into pihole.toml. Then the file is renamed to custom.list.bck. From this point on, FTL abandons this file and will now use /etc/pihole/hosts/custom.list. The old /etc/pihole/custom.list can be removed manually. I don't think we need a cleaning strategy here as only beta users will have this file as a remnant. Users freshly upgrading will not see this file there once this PR got merged.

One other note: I removed rotation of custom.list as it can fully be reconstructed from pihole.toml - we should think about only rotating pihole.toml (and dhcp.leases on Teleporter import) in the future as the same holds true for dnsmasq.conf

Related issue or feature (if applicable): N/A

Pull request in docs with documentation (if applicable): N/A

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• The code change is tested and works locally.
• I based my code and PRs against the repositories developmental branch.
• I signed off all commits. Pi-hole enforces the DCO for all contributions
• I signed all my commits. Pi-hole requires signatures to verify authorship
• I have read the above and my PR is ready for review.