cli service: Allow user to opt-in on not deleting applied file

[cathay4t]

Previously, we introduced new method on finding un-applied state YAML
files. It was a changed behaviour which break API.

This patch change nmstatectl service to original behaviour which just
rename applied YAML file with .applied postfix.

If you don't want the applied state been deleted, please place
/etc/nmstate/nmstate.conf (folder can be defined by --config
argument) with content of:

[service]
delete_applied = false

Manpage updated.

Integration test case included.

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/nmstate-nmstate-2546
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[drawks]

I don't know enough rust to evaluate the code in this diff, but I do want to clarify, historic behavior was to apply all network state files ending with .yml and not to make any attempt at skipping application of files which may have been previously applied. Each of these files declares a state and nothing prevents a later file from mutating a state declared in an earlier file; ergo ALL files must be applied in order to maintain the same behavior as before.

I'm being very specific here because configuring network interfaces is a very foundational bit of configuration and changing this behavior may leave some hosts with broken network configs which can be a SEV 1 type outage.

Consider a case where an operator has configuration management dropping 2 files in /etc/nmstate, 000-reset.yml and 100-configure-defaults.yml where the first file deletes various interface and route configurations to establish a known initial state and then in the second file applies the intended end state. It would break networking if the contents of 000-reset.yml were changed and were resultantly re-applied while the contents of 100-configure-defaults.yml were unchanged and then not re-applied. You will have effectively stopped nmstate service from declarative applying the intended configuration AND will have left the host in a configuration which has no working networking.

The above example is only an example, but it is meant to illustrate the importance of EXACTLY preserving the default behavior of this tool until/unless a behavioral change is released as part of a major version change and/or is well documented and disclosed in a series of "coming breaking change/deprecation" notices.

[cathay4t]

@drawks Thanks for the detailed use case.

I have included test case test_nmstate_service_remove_applied_file_by_default to make sure nmstate.service remove the applied file.

By default, nmstate.service apply all .yml files in /etc/nmstate folder.

Any user want to keep applied by as it was, they can opt-in by create /etc/nmstate/nmstate.conf with content:

[service]
delete_applied = false

In general, this PR is restoring the old behavior and we have test to ensure that.

[qinqon]

Just a nit on the config field name.