The check condition was inverted. Anyway, we should receive IPv4LL
events only when the method is LINK_LOCAL so turn this into an
assertion.

Fixes: b16e09a707fd836cf1ea4ed34422158c8408d94f

https://bugzilla.redhat.com/show_bug.cgi?id=1634657

https://github.com/NetworkManager/NetworkManager/pull/256

There is really no problem here, allow it.

Previously we would assert against a non-zero prefix length.
But I am not sure that all callers really ensured that this
couldn't happen. Anyway, there is no problem we such addresses,
really.

Only we need to make sure that nm_ip4_config_add_dependent_routes()
and nm_ip6_config_add_dependent_routes() don't add prefix routes for
such addresses (which is the case now).

Preface: RFC 3442 (The Classless Static Route Option for Dynamic Host
Configuration Protocol (DHCP) version 4) states:

   If the DHCP server returns both a Classless Static Routes option and
   a Router option, the DHCP client MUST ignore the Router option.

   Similarly, if the DHCP server returns both a Classless Static Routes
   option and a Static Routes option, the DHCP client MUST ignore the
   Static Routes option.

Changes:

- sd_dhcp_lease_get_routes() returns the combination of both option 33
(static routes) and 121 (classless static routes). If classless static
routes are provided, the state routes must be ignored.

- we collect the options hash that we expose on D-Bus. For that purpose,
we must not merge both option types as classless static routes. Instead,
we want to expose the values like we received them originally: as two
different options.

- we continue our deviation from RFC 3442, when receiving classless static
routes with option 3 (Router), we only ignore the router if we didn't
already receive a default route via classless static routes.

- in the past, NetworkManager treated the default route specially, and
one device could only have one default route. That limitation was
already (partly) lifted by commit 5c299454b49b165f645c25fd3e083c0bb747ad91
(core: rework tracking of gateway/default-route in ip-config). However,
from DHCP we still would only accept one default route. Fix that for
internal client. Installing multiple default routes might make sense, as
kernel apparently can skip unreachable routers (as it notes via ICMP
messages) (rh#1634657).

https://bugzilla.redhat.com/show_bug.cgi?id=1634657

In ip4_start(), we iterate over @dhcp4_requests array and add the
options that are to be included. We do so, by calling
sd_dhcp_client_set_request_option().

Note that sd_dhcp_client_set_request_option() only appends the options
to a list, not taking special care about the order in which options are
added.

RFC 3442 (The Classless Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4) says:

   DHCP clients that support this option and send a parameter request
   list MAY also request the Static Routes option, for compatibility
   with older servers that don't support Classless Static Routes.  The
   Classless Static Routes option code MUST appear in the parameter
   request list prior to both the Router option code and the Static
   Routes option code, if present.

Compare to RFC 2132 (DHCP Options and BOOTP Vendor Extensions) which says
about the parameter request list:

   The client MAY list the options in order of preference.

Note, with RFC 7844 (Anonymity Profiles for DHCP Clients), the order
should be randomized. But since we don't follow RFC 7844 (yet), let's follow
at least RFC 3442.

Since sd_dhcp_lease_get_routes() returns the list of all routes,
the caller may need to differenciate whether the route was option
33 (static-routes) or 121 (classless-static-route).

Add an accessor for the internal field.

systemd-pull-request: #10951

Combine same code.