Fixes #26697. RFE.

We'd return -1 (-EPERM), even though we have a general rule to use real errno
values. The particular case that caught my attention was:

$ sudo udevadm control -l asdf
Failed to parse log priority 'asdf': Operation not permitted

... but "git grep 'r =.*_from_string' src/" return 110 hits. Confusingly, some
of the _from_string functions already return a proper errno value, so not all
of those are broken, but probably quite a few.

In hostnamed this is exposed as a dbus property, and in the logs in both
places.

This is of interest to network management software and such: if the fallback
hostname is used, it's not as useful as the real configured thing. Right now
various programs try to guess the source of hostname by looking at the string.
E.g. "localhost" is assumed to be not the real hostname, but "fedora" is. Any
such attempts are bound to fail, because we cannot distinguish "fedora" (a
fallback value set by a distro), from "fedora" (received from reverse dns),
from "fedora" read from /etc/hostname.

/run/systemd/fallback-hostname is written with the fallback hostname when
either pid1 or hostnamed sets the kernel hostname to the fallback value. Why
remember the fallback value and not the transient hostname in /run/hostname
instead?
We have three hostname types: "static", "transient", fallback".
– Distinguishing "static" is easy: the hostname that is set matches what
  is in /etc/hostname.
– Distingiushing "transient" and "fallback" is not easy. And the
  "transient" hostname may be set outside of pid1+hostnamed. In particular,
  it may be set by container manager, some non-systemd tool in the initramfs,
  or even by a direct call. All those mechanisms count as "transient". Trying
  to get those cases to write /run/hostname is futile. It is much easier to
  isolate the "fallback" case which is mostly under our control.
And since the file is only used as a flag to mark the hostname as fallback,
it can be hidden inside of our /run/systemd directory.

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

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

From https://github.com/systemd/systemd/issues/13316#issuecomment-582906817:
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 29e81083bd2fcb2dbf83f67ef358c7d25adf7e9d. There is no
special "fallback" mode now, so the check doesn't make sense anymore.