we now use slapos.cookbook:wrapper instead

Instead of letting `python setup.py test` install the depencies, use
buildout way of installing the eggs.

This software use `interpreter` recipe of `zc.recipe.egg` to install a
python with all eggs pre-installed. This is a way to get all the
dependencies at install time instead of getting them at run time from
pypi when running `python setup.py test`.
`erp5.util.testsuite` has been extended to support a parameter to
specify which python interpreter to use.

One issue is that this way of installing eggs by buildout cause chicken
and egg problem: cloning repository containing `slapos.recipe.cmmi`
needs git, and to compiling git needs `slapos.recipe.cmmi`.
The consequence of this is that re-running software will install too
many parts again.
One solution for this would be to clone `slapos.recipe.cmmi` with a
`git` command provided by testnode or system package.
Another solution would be to not install `slapos.recipe.cmmi` develop
egg, simply install the egg from it's current pypi version while
installing the software (running tests will be from the git checkout
anyway).
For now this is open issue.

Another point of attention is that `python setup.py test` install the
requirements listed in `test_requires`, but `zc.recipe.egg` does not
provide a way of installing these. Some of our packages have `[test]`
entrypoints, in this case, the software installs the test entrypoints.
For others, we install the eggs.

Other improvements:
 * use a simple `slapos.recipe:wrapper` instead of `slapos.cookbook:egg_test`
 * fix the typo in repository name erp5-util-repository ->
   erp5.util-repository ( this mean we will have to fix the test suites in
   nexedi ERP5 )
 * document "what is this software" and a scenario of how this software
   can be used to develop slapos eggs.
 * switch to buildout-hash.cfg for easier template hash management.

/reviewed-on nexedi/slapos!308

https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27xlocale.h.27

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81712

monitor: move scripts wrapper and logrotate conf to buildout, uses some new promises from slapos.toolbox

monitor was updated in slapos.toolbox to not generate promise launcher scripts anymore. All
generated scripts are now in buildout.
Monitor promise run script is removed from cron, slapgrid is used to run promises.
Replace some old promises by the new ones from slapos.toolbox. Cleanup monitor configuration.
Monitor report and monitor-promises directory are now obsolete.

Update verion of lab.nexed.com/kirr/neo.git used and all of its dependencies.

NEO/go now uses 2 Cgo packages:

- github.com/gwenn/gosqlite, and
- github.com/DataDog/czlib

and github.com/soheilhy/cmux to multiplex NEO & HTTP traffic on the same port.

Otherwise it is straighforward update which transitively pulled some more
dependencies.

The most convenient way to discover CFLAGS/LDFLAGS when building Cgo bits is
via pkg-config:

    https://golang.org/cmd/cgo/

For this to work let's add pkg-config to be available there in gowork out of
the box, and provide users with a way to specify which C packages they want to
be there on gowork's $PKG_CONFIG_PATH, e.g. this way:

    [gowork]
    cpkgpath =
        ${sqlite3:location}/lib/pkgconfig
        ${zlib:location}/lib/pkgconfig

In buildout sources cpkgpath is specified as multiline - not one line with ":"
delimiters - with the idea that it should be easy to amend gowork.cpkgpath with "+="
in different places.

Upgrading passes python-2.7 compile and tests. Let's hope it will be ok
everywhere else.

Hello @alain.takoudjou  could you please try to build this branch. 

/reviewed-on nexedi/slapos!305

Rewriting commit history with `git rebase -i` always caused some
conflicts on md5sum of modified files. `update-hash` made all this
easier, because we could just revert buildout.hash.cfg, re-run
`update-hash` and commit the changes.

This tool makes this scenario a bit more user friendly by automating the
steps by running as a git mergetool.

An interactive rebase session can be initiated by running this command
from software/*/ directory:

`git rebase -i --exec "$(pwd)/../../update-hash $(pwd)/buildout.hash.cfg" origin/master`

and if conflict occur, run:

`git mergetool --tool update-hash-mergetool && EDITOR=cat git rebase --continue`

This way, rebase session can be almost non interactive (still have to
run the above mergetool command) when conflicts are only on md5sum
updates.

/reviewed-on !273

New release of Caddy 0.10.11 with updated quic version (v39). 



/reviewed-on nexedi/slapos!301

   This might be refactored in short future with caucase, however for now this change is required to
   slapos master works.

This is a follow-up of commit 5c980caf,
now that the new code of the 'wrapper' recipe is used (1.0.58 released).

Move and rename the mariadb backup restoration script

With this, we don't loose it (it may help an admin to be able to restore it) and it does not get run by webrunner automatically when updating resilience snapshot

/reviewed-on nexedi/slapos!304

Run ERP5 tests under [usershosts](https://lab.nexedi.com/nexedi/userhosts) wrapper with the same host mapping as zope instances.

This will allow to simplify configuration of services such as memcached and also be a more realistic environment.

This revealed problems with userhosts, at least on Debian 9,  that have been fixed in userhosts!2 , so at the same time we update userhosts to get these fixes.

/reviewed-on !303

slapuser4@COMP-2212:~/srv/testnode/bej/inst$ ./test0-5/bin/runner-importer
./test0-5/bin/runner-importer run at : Mon Mar 12 19:55:50 CET 2018
Restoring WebRunner content...
./test0-5/bin/runner-importer: line 49: cd: /srv/slapgrid/slappart4/srv/testnode/bej/inst/test0-5/srv/backup/runner/runner/: No such file or directory

With this, we don't loose it (it may help an admin to be able to restore it) and it does not get run by webrunner automatically when updating resilience snapshot