Complete details of the bug are filed in an issue on the nmstate github

Describe the bug

As of the merge of https://github.com/nmstate/nmstate/commit/dbb98e1d30c727b5e47ea7daacc8f2936ab5a0e0 the behavior of `nmstatectl service` is to store a checksum of the applied configs and not reapply configs that have previously been applied.

This is a breaking change as you can no longer evaluate the contents of the `.applied` file to determine what the current running state should be. The semantics of the behavior of the command have fundamentally changed as well as the contents/format of the files involved in the service. This should not have happened in a patch release (behavior is changed between 2.2.21 and 2.2.22), typically a change of this nature would be implemented in a manner that preserves backwards compatibility and would be in a minor release and removal of backwards compatibility would be noted as a coming deprecation/breaking change to be subsequently included in a major release.

nmstate version: 2.2.23

NetworkManager version: 1.44.0

Platform: rhel 9.3

How reproducible:100%

Steps to Reproduce

1. create a file `/etc/nmstate/somechanges.yml` with some changes to be made
2. run `sudo nmstatectl service`
3. observe that:
   1. `/etc/nmstate/somechanges.yml` is still present unlike in previous versions
   2.  `/etc/nmstate/somechanges.applied` file contains a sha256 digest instead of being a full copy of the applied change as in previous versions
   3.  any software integration that depended on the previous documented behavior is now broken in unanticipated ways

Additional context

The motivation for the change is documented as `At some envs like openshift machine-config-operator moving configuration

files can break in place upgrades` which acknowledges that the existing behavior exists and the change fundamentally changes how this command behaves. It is inappropriate and unexpected that a downstream consumer of the nmstate failing to work correctly within the documented behavior of the software would be enough to motivate a breaking change in a patch release that is subsequently pushed out to a stable release of an enterprise OS distribution. @qinqon as an employee of Redhat I'm surprised to see that you signed off on this change

Also, it should be noted that the accepted change does not include any update to the manpage for `nmstatectl` which still says:

service
Apply all network state files ending with .yml in specified( default: /etc/nmstate) folder. The applied network
state file will be renamed with postfix .applied to prevent repeated applied on next run.

and the changelog fails to not that any breaking changes were included in the release instead declaring the changed behavior as a "bugfix" even though the original behavior was documented and behaved exactly as documented. Typically a "bug" is a behavior that varies from the expected and documented behavior.