with a backported patch to fix compilation with gcc 10

On Debian 10 the test was successful because it could use the system
python (usr/bin/python). In Debian 11 the system python isn't available
anymore, therefore it fails. To ensure the Fluentd program can successfully
execute the "python custom_read_bme280.py" command, the script passes
the same python binary to the Fluentd config file with which the test
is called (sys.executable).

@romain reports that Popen(close_fds=True) is slow on py2. Let's semantically
backport from py3 how to close only actually opened file descriptors instead of
whole 3..`ulimit -n` range.

Attached test benchmark shows the following results with `ulimit -n`=65K:

Before this patch:

    $ ./bin/python2.7 ~/x.py
    close_fds=False:
    0.001251 s/call
    0.001337 s/call
    0.001486 s/call

    close_fds=True:
    0.017973 s/call
    0.018152 s/call
    0.018204 s/call

After the patch:

    $ ./bin/python2.7 ~/x.py
    close_fds=False:
    0.001391 s/call
    0.001416 s/call
    0.001570 s/call

    close_fds=True:
    0.001469 s/call
    0.001479 s/call
    0.001491 s/call

i.e. ~12x speedup.

References on this subject are in the patch itself.

The test benchmark is below:

---- 8< ----
import timeit
from subprocess import check_call

def f():
    check_call(['true'], close_fds=False)
def g():
    check_call(['true'], close_fds=True)

N=3
n=100
print 'close_fds=False:'
for i in range(N):
    print '%.6f s/call' % (timeit.timeit(f, number=n) / n)
print
print 'close_fds=True:'
for i in range(N):
    print '%.6f s/call' % (timeit.timeit(g, number=n) / n)

/helped-by @jm

This version fixes build for debian >= 11

On debian 11, linking against libnsl link against several system
libraries and the check software check fail.

these are dependencies of postfix

  - access log
    - log rotation
    - username is logged (expected failure in WSGI)
  - event log
    - log rotation
  - long requests log (expected failure in WSGI)
    - log rotation
  - activity processing
  - deadlock debugger

so that we can use them in setUpClass

Since ERP5 commit d4eda7ea49 (CMFActivity: show InnoDB history list
length in console watcher, 2020-09-15), the wrapper script no longer work
because accessing history list length require PROCESS privileges.

In the case of ERP5, mariadb database is dedicated for ERP5, so we can
grant the PROCESS privilege also to erp5 default user, which is used in
the wrapper script.

We don't grant the permission to test users because they don't need it.

also access urllib3 from its real location

sort import and don't use map & range from six, they are used in a way
that leads to same results in python 2 or 3

See merge request nexedi/slapos!1092

Communication between repman and mariadb can now use ssl for
secure connection.
Proxysql is also configured to work with ssl, user access
database with secure connection.

Also solve when database initial user created with authentication plugin socket on
master database doesn't exist on slave database mariadb
because there are running diffrent slapuser.

OPENED ERR00056 : Master user 'slapuser4'@'localhost' is not defined on
replication candidate [2001:67c:1254:e:5:513b:0:5f35]:2199

To add a Database, user should request a slave instance. Each slave
instance is a database.

- Destroy slave database if slave instance was destroyed

- Update and remove slave database only on master mariadb

- Allow to create database slave with character sets and collate options

- Generate slave database password if not set

The added zlib dependency is for the bundled prometheus-cpp, else:

CMake Error at .../cmake-3.18/.../share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
Call Stack (most recent call first):
  .../cmake-3.18/.../share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
  .../cmake-3.18/.../share/cmake-3.18/Modules/FindZLIB.cmake:115 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  pull/CMakeLists.txt:9 (find_package)

So far, it "worked" because Python 2 was found on the system.
Not the case anymore in our Debian 11 test nodes.