Comment 31 for bug 1694159

It turns out mv_conffile + package rename doesn't work correctly.
It would not realize there was a changed conffile and drop the old content completely.
It would neither retain in moved file, nor in dpkg-bak which is the worst case.

Furthermore and more important is that the the combination of
  mv A B oldver
  rm B newver
doesn't work.
This is needed to mv-retain data on LTS->LTS upgrade which "can still be saved".
While at the same time drop obsolete conffiles (including retain custom data in backups)
But instead the preinst of the RM will make the conffile unavailable for the postinst of the MV.
The postinst of RM will then remove it.
So that is equivalent to "just" RM.
Note: if MV finds an equal md5sum it is actually a RM in via .dpkg-remove
Overview:
          diff default
pre mv - does nothing mv .dpkg-remove
pre rm - mv .dpkg-backup mv .dpkg-remove
post rm - would mv, but named .dpkg-backup now rm .dpkg-remove
post rm - .dpkg-backup to dpkg-bak rm .dpkg-remove

The conffiles that changed were those that almost never have user changes, still we want to make it correct. So the implmentation tries to move old changes where applicable, but in a few cases only creates backups to not interfere too much.
So likle 99% of the cases there won't be changes anyway and it will just be deletes to clean up.

It turns out there also was a non packaged symlink (created in maintainer scripts) that had to be taken care of.

So we need another tweak which - just in the critical combination fixes
up the "state machine" to work with install/upgrade/abort but also both combinations of RM/MV as needed.
To do so if in these special "version window" in preinst after DEBHELPER we need to undo the RM (only if happened which matches that there were custom changes, but keep it in all other cases)

Finally the changes in /etc/init.d/libvirt-bin are critical throughout the update, we don't want those to be moved. Through the combo of renaming plus package change that would cause issues with insserv (or need even more hacky workarounds). Therefore for that we only want to create the .dpkg-bak and message if it was modified (unlikely anyway).