It will generate new csr and key if the template changes, also if beacuse of
some reason key or csr is not present anymore.

This change makes the part resist to cases when it is becoming uninstalled and
installed again, so that it will not shoot its own foot and leaving the macro
user in inconsistent state.

Sorting will make dumped data "canonical", so it will limit amount of order
based changes.

Destroyed nodes shall be just destroyed, and there is no need to send whole
configuration to them.

This will stabilise list of published slaves.

Server returns slave list with request and publish keys, but only request keys
are important.

In order to avoid needless updates and nonsense data remove those polluted
keys before publishing information about each slave.

hash-existing-files list all the files used for hash that are not
handled by buildout. For those files, the hash is calculated as soon as
the __init__ function so that if there is a change in those files,
buildout will remove the existing wrapper (it will uninstall the
section) and replace it with the new wrapper.

Extract get-pip change in a separate commit
cc @jm @romain

/reviewed-on nexedi/slapos!621

Using WSGI became the default behavior in
f4d141a1.

--user=root is redundant and it will break with MariaDB 10.4

This is important for performance and it enables testless promises.

For partitions that are instantiated successfully, let slapos decide
when there's no parameter change (usually once a day).

Instantiation can be forced on manual action in the UI.

Remove method `generateHashFromFiles` in all file `test.py`, import it from `slapos.recipe.librecipe`.

/reviewed-on nexedi/slapos!617

/reviewed-on !611