This way buildout can reuse egg caches and it's a bit faster:

To run a simple instance buildout, from 2.837s it goes down to 1.875s.
To run slapos node instance 10 times just after requesting an ERP5 instance, it goes from ~112s to 98s

before
    hyperfine "/srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U"
    Benchmark #1: /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U
      Time (mean ± σ):      2.837 s ±  0.275 s    [User: 2.481 s, System: 0.285 s]
      Range (min … max):    2.482 s …  3.222 s    10 runs

after
    hyperfine "/srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U"
    Benchmark #1: /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/shared/python2.7/60364a13cc977dd5a894e0239ac889b9/bin/python2.7 /srv/slapgrid/slappart4/srv/slapos/inst/slappart0/tmp/soft/c63ba7265399450b28f9ea6d5667a5e7/bin/buildout -U
      Time (mean ± σ):      1.875 s ±  0.067 s    [User: 1.660 s, System: 0.148 s]
      Range (min … max):    1.816 s …  2.038 s    10 runs

test will be much slower, but having two slaprunner compiling at the same time
in the same folder is not something supported.

Since 0.9.6 caucase stopped using the 128bits OID arc that caddy/golang does
not support, so nothing prevents us from using a caucase certiciate now.

See merge request nexedi/slapos!838

We don't plan using varnish like this.

See merge request nexedi/slapos!836

stop-on-error during instantiation can lead to endless instantiation in some
cases, which disallows to create services required for given part to pass, and
in the same time in many cases the called scripts are smart enough to continue
and restart on error.

Thanks to this, it's much easier to find relevant configuration, and also logs
are becoming much more informative.

Avoid creating needless entries and minimise needless newlines, and reflect
this in test data, as in such case no backend_log is created, as nothing is
configured on backend Haproxy level.

SSL cache is unusable in context of caddy, same for the so called HTTPD home.
Those are old Apache leftovers.

It's a dict, and in SlapOS usage of Jinja2 it's good to see the type of
a variable immediately.

"parameter_dict" says nothing, whereas "software_parameter_dict" explains
source and purpose of the information.

There is needless duplication of information.

That's true, that those are templates, but the important information which
shall be in the name of the parameter is its purpose - a profile.