Merge branch 'cython_nogil' of https://lab.nexedi.com/gsamain/slapos into cython_nogil

Compare the result which generated from Cython environment
Instead print a determined string

In "direct zope access" ports, the shared frontend is not used, so
the argument that long timeout consume resources on shared server does
not apply here.

A timeout of one hour was choosen arbitrarily, a value that should be
large enough for normal requests and more than the default 60s timeout
that we hit in the "wait for activities" step when running zelenium
tests.

In 51740961 we "started testing new version of setuptools" and `BUILDOUT-NEXT` test suite was set to use this `software/buildout-testing/software-next.cfg`.

In nexedi/slapos!425 we started to depend on very recent setuptools and updated to 40.4.3 .

This `software/buildout-testing/software-next.cfg` kept using this old setuptools and `BUILDOUT-NEXT` test suite failed to build in a loop.

The test suite was already changed to use `software/buildout-testing/software.cfg` (ie. it's same as `BUILDOUT` but testing slapos.buildout's  `next` branch instead of `master` ), so I think this profile is not needed currently.

/reviewed-on nexedi/slapos!488

Using `software11` breaks now that the version of the database was
increased in nexedi/slapos.core!76

/reviewed-on nexedi/slapos!483

/reviewed-on nexedi/slapos!489

/reviewed-on nexedi/slapos!469

  Before call uninstall, the pin is verified and it can cause error if picked version is mandatory.

Just asserting Location header is not enough, as http status code value is
important for the implementation, so assert for its value.

Also fix https-only redirect status code value, which supposed to be FOUND,
not default MOVED_PERMANENTLY.

/reviewed-on nexedi/slapos!485

/reviewed-on nexedi/slapos!487

/reviewed-on nexedi/slapos!486

   The version 1.0.84 was used by an existing tag on the
   version control, so it would be inconsistent to use this
   version number.

It is known problem of Caddy regarding QUIC non functional after sending it
SIGUSR1: https://github.com/mholt/caddy/issues/2394

/reviewed-on nexedi/slapos!481

/reviewed-on nexedi/slapos!480

Installing from master is problematic because when master does not build
we don't have test results and we don't see that it's broken.

/reviewed-on nexedi/slapos!474

The query present in the sql dump sets gtid_slave_pos, which is used by
slave_pos. current_pos relies on gtid_current_pos, which is not set here
and hence fails to initiate replication.
Another (unintended) effect of using slave_pos is that queries run on the
slave will not break replication. There should be no reason to run queries
on slave (at least, data & schema modification queries while replication
is active), so it would seem better to fail the replication immediately in
order to detect this. So this may not be the best solution - but at least
this fixes this script.