device: refactor reapply_connection()lr/reapply

Reapplying a connection should not be done by iterating over and
(unsorted) @diffs array. Instead the order matters! E.g. first layer 2
before IP settings. Thus extracting those individual updates on a per-setting
base to different reapply_*() functions is more complicated, albeit incorrect
in complex cases. We need full control over how to reapply changes, one
after the other.

Also, once we start applying changes, we cannot really abort on error.
We can only continue best-effort and hope for the best.

Also, always reapply certain settings, even if the configuration doesn't
change. That means, if the user externally deletes a static IP address,
he can call reapply() to restore it. Even though he doesn't provide a
different setting to apply.

Also revert the changes to nm_device_reapply_settings_immediately().
Effectively there is little code that can be reused.

Add audit logging.

0 files changed, 0 insertions, 0 deletions