See merge request !779

fixup of 6fbc6e15

The version we were using did not support timing diagrams.

Update to a more recent version where it's supported.

See merge request !778

This is a new feature requiring a recent plantuml version

Rendering of some diagrams to png is slightly different, images are not
same size

To fix caucased failures:
  File "caucase/caucase/http.py", line 799, in main
    http_cas=http_cas,
  File "caucase/caucase/http.py", line 397, in getSSLContext
    http_cas.createCertificate(csr_id)
  File "caucase/caucase/ca.py", line 281, in createCertificate
    template_csr=template_csr,
  File "caucase/caucase/ca.py", line 328, in _createCertificate
    x509.SubjectKeyIdentifier,
  File "cryptography-2.3.1-py2.7-linux-x86_64.egg/cryptography/x509/extensions.py", line 189, in from_issuer_subject_key_identifier
    key_identifier=ski.value.digest,
AttributeError: 'SubjectKeyIdentifier' object has no attribute 'value'

In turn, this requires updating cryptography dependencies.
In turn, this requires updating requests as our old version is
incompatible with current idna version.
In turn, this requires updating requests dependencies.
And finally, this allows/requires updating some pins in SRs:
- software/jupyter: Version up certifi.
- stack/erp5: Un-pin chardet, as it is already pinned at stack/slapos level.

Building PyPy from source is a nightmare and the shipped top-level
Makefile is a joke:
- nothing configurable at top-level to do the 2 common operations:
  build & install;
- the main binary searches for the library at hardcoded and
  undocumented places relative to where it is installed;
- no option to exclude specific components ? (here, _tkinter);
- lack documentation to specify location of required libraries;
- nothing out-of-the-box to build with several cores (it's even
  strange that in 2020, the biggest part is single threaded and
  it can't be resumed; I'm curious to know how developers work).

I found many answers in the Debian packaging.

This commit creates a Makefile file for 2 reasons:
- slapos.recipe.cmmi (forked from hexagonit.recipe.cmmi)
  does not have options to specify a shell snippet that is
  executed only during the build step
- by splitting the build in several steps, it makes debugging
  easier when it does not have to rebuild from the beginning

The drawback is that:
- make recipes need to be indented with tabs,
  in addition to the buildout indent of 2 spaces;
- $ escaping is tricky.

forcediphttpsadapter does not work with requests' SourceAddressAdapter,
so by following https://stackoverflow.com/a/44378047/9256748 implement
own curl's --resolve style.

On backend side headers are asserted in tests:

 * X-Forwarded-For
 * X-Forwarded-Proto
 * X-Forwarded-Port
 * Host

In order to pass cleanly X-Forwarded-For from the frontend to the backend,
it's passed as X-Forwarded-For-Real in case of cached slaves.

Noted problem with IPv6 endpoint was used, as in this case 6tunnel IP would
be used.

QUIC is not used at all, and became superseded by HTTP/3

Customized configuration support is not used since introduction of
Caddy software, so there is no need to support it anymore.

stack/erp5: put a magic parameter to use the first entry of X-Forwarded-For as the source IP address.

See merge request nexedi/slapos!776

because we anyway has never used log, but just use stderr ourput.

in HAProxy 2.0, httpclose has the same meaning as forceclose, that is deprecated.

also add CPU=native for possibly better performance.