dnsmasq: migrate dhcpv4/dhcpv6 default on upgrade

dnsmasq: migrate dhcpv4/dhcpv6 default on upgrade

Commit 6f30f08d0e ("dnsmasq: add fallback for default dhcpv4/dhcpv6
values") changed dnsmasq.init to default the 'dhcpv4'/'dhcpv6' UCI
options to 'disabled' when a 'config dhcp' section leaves them unset:

  -	config_get dhcpv4 "$cfg" dhcpv4
  -	config_get dhcpv6 "$cfg" dhcpv6
  +	config_get dhcpv4 "$cfg" dhcpv4 disabled
  +	config_get dhcpv6 "$cfg" dhcpv6 disabled

The intent was to match odhcpd, which already treats an unset value
as disabled, so both backends behave the same way for newly created
configs. Its companion commit 85767ac8fe added explicit
'option dhcpv4/dhcpv6 server' lines to the stock 'lan' section in the
packaged dhcp.conf template, which covers fresh installs.

Neither commit accounts for configs that predate the change. Before
it, an unset dhcpv4/dhcpv6 option was implicitly treated as enabled,
so it was common (and still is, on any router upgraded from before
this landed) to have 'config dhcp' sections for additional
interfaces/VLANs with no explicit dhcpv4/dhcpv6 option at all. After
the change, dnsmasq.init silently skips '--dhcp-range' for every one
of those sections:

	if [ "$dhcpv4" != "disabled" ]; then
		...
	fi

The result: any interface whose dhcp section never needed the option
before stops handing out leases entirely, with nothing logged beyond
a normal dnsmasq startup, while sections that happen to already carry
an explicit 'server' value keep working. On a router with several
VLANs this looks exactly like "DHCP only works on one interface."

Fix by shipping a one-time /etc/uci-defaults migration, matching the
existing 50-dnsmasq-migrate-resolv-conf-auto.sh /
50-dnsmasq-migrate-ipset.sh pattern in this package: for every
'config dhcp' section, if dhcpv4/dhcpv6 is unset, explicitly set it
to 'server', preserving the pre-6f30f08d0e behavior for existing
configs. Sections that already set the option (or set 'disabled'
deliberately) are left untouched, and sections that never reach the
check (e.g. 'wan' with 'option ignore 1') are unaffected.

Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/24068
Signed-off-by: Robert Marko <robimarko@gmail.com>