…lues

They are not really boolean, because we have both ipv4 and ipv6, but
for each protocol we have either unset, no, and yes.

From systemd#13316 (comment):
LinkLocalAddressing must be a boolean option, at least for ipv4:
- LinkLocalAddressing=no => no LL at all.

- LinkLocalAddressing=yes + Static Address => invalid configuration, warn and
  interpret as LinkLocalAddressing=no, no LL at all.

(we check that during parsing and reject)

- LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the
  DHCP one, an LL address must be acquired at start or after a short N
  unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a
  DHCP address is acquired, drop the LL address. If the DHCP address is lost,
  re-adquire a new LL address.

(next patch will move in this direction)

- LinkLocalAddressing=fallback has no reason to exist, because LL address must
  always be allocated as a fallback option when using DHCP. Having both DHCP
  and LL address at the same time is an RFC violation, so
  LinkLocalAdressing=yes correctly implemented is already the "fallback"
  behavior. The fallback option must be deprecated and if present in older
  configs must be interpreted as LinkLocalAddressing=yes.

(removed)

- And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL
  address aren't required to be always set for every IPv6 enabled interface (in
  this case, coexisting with static or dynamic address if any)? Shouldn't be
  always =yes?

(good question)

This effectively reverts 29e8108. There is no
special "fallback" mode now, so the check doesn't make sense anymore.

So far we only reported major state transitions like failure to acquire
the message. Let's report the initial failure after a few timeouts in
a new event type.

The number of timeouts is hardcoded as 3, since Windows seems to be using
that. I don't think we need to make this configurable out of the box. A
reasonable default may be enough.

Fixes systemd#13316.