Going from 0.0.0.dev4 to -> 0.0.0.dev8 zodbtools:

- Stabilized `zodb dump` format and layed ground for `zodb restore`;
- Taught `zodb analyze` to work with any ZODB storage (instead of being
  FileStorage-only tool) and to analyze a particular range of history
  (instead of crunching data for days on a large database);
- Added `zodb commit` tool that is handy in testing;
- Added ability to specify tid ranges in human-readable format, as in
  e.g. `zodb analyze data.fs 2018-01-01T10:30:00Z..yesterday`.
- Progressed on Python3 support.

See https://pypi.org/project/zodbtools/#zodbtools-change-history
for details.

Close to non-functional change, but removes PendingDeprecationWarning
about cgi.parse_qsl

0.0.0.dev4 to 0.0.7.post1 goes a long way. See
https://pypi.org/project/pygolang/#pygolang-change-history for details.

Recent pygolang is needed for wendelin.core 2.
Zodbtools also uses it starting from v0.0.0.dev5.

We already patch ZEO4 with TCP_NODELAY patch (see 5cf4cf1f "ERP5:
enable TCP_NODELAY for ZEO") and we will need to backport more patches
to ZEO4 branch for wendelin.core 2 to work correctly.

It's not only software/neoppod which uses ZEO, and it is not convenient for
all other software-releases to inherit from neoppod to use correct
version and build of ZEO egg. For this reason factor out details of ZEO
egg building into component/ZEO and let users use ${ZEO:egg} where ZEO
is needed. This way ZEO will be correctly installed for all users.

This patch should be a non-functional change. We switch to
ZEO@5114f909 revision which corresponds to ZEO 4.3.1 +
TCP_NODELAY.patch

Adding other patches to ZEO4 needed by wendelin.core 2 will be done as a
separate step.

5.2.2 brings in important fix that is needed for wendelin.core 2:
https://github.com/zopefoundation/ZEO/pull/160

They say that `zodbpickle.binary` is now much more lightweight on CPython2:
https://github.com/zopefoundation/zodbpickle/blob/master/CHANGES.rst#200-2019-11-13

software/caddy-frontend implements all requirements and apache-frontend is
not tested neither developed except small fixes, so it's ok to keep it for
reference or some small work outside of official tree, as other developers
might have urge to use it.

*  Updates component/pureftpd url to 1.0.49 version because the one provided do not exist anymore (the 1.0.46 version exists now under the path [https://download.pureftpd.org/pub/pure-ftpd/releases/obsolete/pure-ftpd-1.0.46.tar.bz2](https://download.pureftpd.org/pub/pure-ftpd/releases/obsolete/pure-ftpd-1.0.46.tar.bz2))
*  Deletes explicit slapos.toolbox dependency because it's automatically installed by monitor stack

See merge request nexedi/slapos!834

* syntax highlighting for git commit message and git rebase
* include a slapos logo
* Include some better monospace fonts (Source Code Pro and Jetbrains Mono)

See merge request nexedi/slapos!831

See merge request nexedi/slapos!833

This reverts commit 3d12ddae.

The commit was instroducing errors in compilation or at runtime.

Compilation error were like (for cmake in Debian 8 machine):
[ 99%] Built target CTestLib
[100%] Built target ctest
Install the project...
bin/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by bin/cmake)
bin/cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by bin/cmake)
Makefile:72: recipe for target 'install' failed
make: *** [install] Error 1
cmake: Command 'set -e;make  install' returned non-zero exit status 2
cmake: Compilation error. The package is left as is at /srv/slapgrid/slappart61/srv/runner/shared/cmake/9fc4b0e8f4f03ce17eb7ef43525d2238__compile__/cmake-3.7.2 where you can inspect what went wrong.

Runtime errors were like (for mariadb in Debian 9):
Traceback (most recent call last):
  File "/srv/slapgrid/slappart13/srv/testnode/dfg/soft/e2d325c0fcfb592bc760fe363ac5b17a/parts/slapos.core-repository/slapos/testing/testcase.py", line 168, in setUpModule
    installSoftwareUrlList(cls, [software_url], debug=debug)
  File "/srv/slapgrid/slappart13/srv/testnode/dfg/soft/e2d325c0fcfb592bc760fe363ac5b17a/parts/slapos.core-repository/slapos/testing/testcase.py", line 378, in installSoftwareUrlList
    checkSoftware(cls.slap, software_url)
  File "/srv/slapgrid/slappart13/srv/testnode/dfg/soft/e2d325c0fcfb592bc760fe363ac5b17a/parts/slapos.core-repository/slapos/testing/testcase.py", line 336, in checkSoftware
    raise RuntimeError('\n'.join(error_list))
RuntimeError: /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/mysql_ldb has some not found libraries:
/srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/mysql_ldb: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/mysql_ldb)
/srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/sst_dump has some not found libraries:
/srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/sst_dump: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /srv/slapgrid/slappart13/srv/testnode/dfg/inst/test0-0/tmp/shared/mariadb/46cf3950f79675ddccafc1c99a13e734/bin/sst_dump)

Be nice test and clean up your own mess.

~/bin/slapos script does not overwrite $SLAPOS_CONFIGURATION if it's set,
to prevent service accidentally use another slapos.cfg if $SLAPOS_CONFIGURATION
is set for some reason, explicit pass the path of the slapos.cfg

This solves vulnerabilities reported by npm upon installation.

We'd prefer ld to always take LD_RUN_PATH into account, even if any
rpath is specified in the command-line. We could actually change the
wrapper this way but it would not be consistent with the case where
the SR is built with system gcc.

See merge request nexedi/slapos!820

This is quite an ugly workaround

This addresses both :
 - some random failures we sometimes have when installing `python-language-server` fail
 - caddy no longer being installed here since nexedi/slapos!821

See merge request nexedi/slapos!828

It has to be ensured, that parameters are correctly passed to the partitions.

Each node allows for global statistic access for full backend-haproxy, which
is exposed using special frontend, and then transferred back to the master
partition, so that the administrator can access it.

Prevent this kind of errors when first installation fail:

    Error: [Errno 13] Permission denied: 'parts/python-language-server/bin/activate'

by using --clear the virtualenv is recreated from scratch if the command failed
for some reason.