from
https://werkzeug.palletsprojects.com/en/0.14.x/contrib/fixers/#werkzeug.contrib.fixers.ProxyFix
to
https://werkzeug.palletsprojects.com/en/1.0.x/middleware/proxy_fix/#werkzeug.middleware.proxy_fix.ProxyFix

the behavior seems the same, default config in both cases is to trust one
level of proxy.

Monitoring is about states, not exact values, so report the states, as
otherwise it results with bloating databases, very long accesses to results
and long synchronisations.

Instead of many entries like:

http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.02s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.03s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.04s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in 5.01s which is longer than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 0.08s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 1.37s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 0.09s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 1.37s which is shorter than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in 0.09s which is shorter than maximum 5.00s

It's minimised to:

http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: ERROR IP IP replied in more time than maximum 5.00s
http://url/ : http_query: OK status code 302 on IPs IP elapsed_time: OK IP IP replied in less time than maximum 5.00s

This affects:

 * bot_status
 * http_query

Obviously some information are removed from the monitor, but anyway they are
just text entries and not parsable. So other approaches shall be used to make
graphs from those values, which is not covered by pure promise status.

Arguments passed to apachedex are complex, they contain quotes, backslashes,
spaces and they are propagated through several levels of buildout profiles
and scripts.
Simplify all this by relying on argparse ability of passing arguments from
a file. Users of this tool are now expected to generate a config file and
specify the path of this config file as an arguments.

This fixes division by 0.

See merge request !86

Use shlex from standard library which splits arguments properly instead of
implementing our own buggy version.

fixup for ecf144ee

current_project variable is mandatory

"test_networkbench: increase resolution time tolerance" addresses [this](https://erp5.nexedi.net/test_result_module/20200911-8C18D791/14):

```
======================================================================
FAIL: test_dnsbench_fail (slapos.test.test_networkbench.TestDNSBench)
Test dns failure resolution
----------------------------------------------------------------------
Traceback (most recent call last):
File "/srv/slapgrid/slappart20/srv/testnode/cum/inst/test0-0/parts/slapos.toolbox/slapos/test/test_networkbench.py", line 66, in test_dnsbench_fail
self.assertLess(info[3], 1)
AssertionError: 2.0736539363861084 not less than 1
```

"cpu load plugin: fix test and minor cleanups" addresses [this](https://erp5.nexedi.net/test_result_module/20200911-C444DB47/13):

```
======================================================================
ERROR: test_check_cpu_load_run (slapos.test.promise.plugin.test_check_server_cpu_load.TestCheckServerCPULoad)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/slapgrid/slappart9/srv/testnode/bvi/inst/test0-0/parts/slapos.toolbox/slapos/test/promise/plugin/test_check_server_cpu_load.py", line 48, in test_check_cpu_load_run
    self.launcher.run()
  File "/srv/slapgrid/slappart9/srv/testnode/bvi/soft/65dbbd3d11daa99cf78c9566a0a4798e/parts/slapos.core-repository/slapos/grid/promise/__init__.py", line 884, in run
    failed_promise_output))
PromiseError: Promise 'server-cpu-load-promise.py' failed with output: Error: Promise timed out after 0.5 seconds
```
Some more fixes are in nexedi/slapos!809

See merge request nexedi/slapos.toolbox!85

Sometimes it's not enough, as we can guess from the tests failures.

See merge request nexedi/slapos.toolbox!84

We don't really care how long DNS resolution took here, since we see
cases where on test machines a name resolution takes more than one second,
increase the minimal time to something higher to prevent such failures.

Also remove not used commented out code.

This test was failing randomly because it uses a timeout of 0.5 seconds, which
is sometimes not enough to run commands.

Increase the timeout to something large enough so that we don't have timeout
failures when test machine is busy.

Also simplify the whole thing by using python instead of parsing the output
of processes.

- from now on we want the reports as .xz
- fix type argument parsing which should make the promise effective now

See merge request nexedi/slapos.toolbox!83

this was not html.

Also use os.path.join to manipulate paths

this program was comparing floats parsed from the report text and strings from
arguments passed on the command line, so basically it was not doing what was
intended.

because pt-query-digest are text files that can be large, we should except that
the users have compressed them.

See merge request !79

This reverts commit 87b96e1b.

This reverts commit 099295af.

This reverts commit a0aa8b35.

but read only as much as we expect to receive. It should make tests more
stable

As python3 only accept binary types for sockets

Keep log file for debugging and use cleanup function to be sure
to correctly stop services

to simplify the code

See merge request !81