It is important for DevOps to understand which files were modified during
synchronisation procedure in order to track issues fast.

and not in the backuped files.
If we look in the backup files, then of course we find modified files, which are
the ones that have just been copied from the instance folders

/reviewed-on nexedi/slapos.toolbox!53

As these slapparts are unstable and are updated every couples of months.
Do so by using the API-ification of inspectInstance which can now
return a JSON (thus output can be easily processed)

As in webrunner slappart0 is always the root instance and
all needed parameters are bubbled up to it

This shall be helpful when debugging why the data disappeared from a webrunner.

/cc @cedric.leninivin  @jerome @Nicolas @alain.takoudjou @rafael

/reviewed-on nexedi/slapos.toolbox!52

This shall be helpful when debugging why the data disappeared from a
webrunner.

This promises are used in caddy-frontend to check slave frontend status. We don't want to run them everytime buildout will deploy frontend because:
- there is too many slaves, check all slave frontend promises while deploying frontend will slow down slave frontend deployment.
- we don't want to reprocess frontend if one of slave frontend promise is failing

First start of promise migration to new python promises format. Promises migrated here are
used in caddy-frontend and monitor stack.

[webrunner] when displaying connection parameters, sort them in alphabetical order (as done on slapos master)

@jerome @jm @vpelletier @rafael @Nicolas @guillaume.hervier @alain.takoudjou

I tested in my webrunner

/reviewed-on nexedi/slapos.toolbox!48

Function should return True if everything is OK.
Also add some logging

As mentionned by @jerome in 2848a965
fnmatch allows more natural definitions for path manipulations

The promise should not fail if the backup was never launched because the instance just deployed.

/reviewed-on nexedi/slapos.toolbox!47

Thus we have more possibilities in filtering than just excluding
a full directory.