Fail to save a connection with a 'link' setting instead of just
ignoring it. Now:
$ nmcli connection add type ethernet ifname foobar
Connection 'ethernet-foobar' (c3f6f067-e1d5-4bb1-8d67-e09109253a79) successfully added.
$ nmcli connection modify ethernet-foobar link.tx-queue-length 1234
Error: Failed to modify connection 'ethernet-foobar': failed to update connection: The ifcfg-rh plugin doesn't support setting 'link'. If you are modifying an existing connection profile saved in ifcfg-rh format, please migrate the connection to keyfile using 'nmcli connection migrate c3f6f067-e1d5-4bb1-8d67-e09109253a79' or via the Update2() D-Bus API and try again.
$ nmcli connection migrate c3f6f067-e1d5-4bb1-8d67-e09109253a79
Connection 'ethernet-foobar' (c3f6f067-e1d5-4bb1-8d67-e09109253a79) successfully migrated.
$ nmcli connection modify ethernet-foobar link.tx-queue-length 1234
$
Fixes: 39bfcf7aab ('all: add "link" setting')
<description> is now an XML element, no longer an attribute. Fix the
style sheets.
Fixes: 89abede3df ('docs: rework generating property infos to use <description> element')
There is no need that two XML files that essentially hold similar
information are fundamentally different. Make them more alike.
This way, we can use the same tools that operate on either of
these input files.
monitor-connection-files was deprecated and disabled by default for a long
time. In the meantime, it has no effect at all.
Remove references from the manual pages.
`man nm-settings` says about ethernet.mac-address:
If specified, this connection will only apply to the Ethernet device
whose permanent MAC address matches.
This improves the HTML rendering.
But it also causes a lot of non-resolvable linkends warning when rendering a
separate manual pages into roff/mman. The messages are harmless, but still
a bit ugly.
This way it's consistently used across all manual page without a need
for XSL templating.
Also, the entities file could in future possibly be used to template the
build-time configurables such as filesystem paths or bug tracker URL.
It's injected from the makefile, but not even used consistently or included in
the resulting render of manual page. Which is good, otherwise we'd have a
non-reproducible build with possible multilib conflicts if rendered around
midnight.
Since libnm-core secret-flags properties are now enum-typed rather
than just being uints, we can now actually recognize them when
generating docs, rather than just assuming that every property whose
name ends in '-flags', but isn't in NMSettingDcb, is a secret-flags
property.
