Hopefully fix the random failure with:

```
test_connect (test.TestSSHServer) ... /srv/slapgrid/slappart3/srv/testnode/byx/soft/a452c8ac557f7eaea3c20f6cc373c390/eggs/paramiko-2.4.2-py2.7.egg/paramiko/client.py:822: UserWarning: Unknown ecdsa-sha2-nistp521 host key for [2001:67c:1254:e:4a::7bd5]:22222: 22c41f5090433152d1e5395a85d6cb4f
  key.get_name(), hostname, hexlify(key.get_fingerprint())
FAIL

======================================================================
FAIL: test_connect (test.TestSSHServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/slapgrid/slappart3/srv/testnode/byx/soft/a452c8ac557f7eaea3c20f6cc373c390/parts/slapos-repository/software/seleniumserver/test/test.py", line 357, in test_connect
    self.assertIn("Welcome to SlapOS Selenium Server.", channel.recv(100))
AssertionError: 'Welcome to SlapOS Selenium Server.' not found in 'Attempt to write login records by non-root user (aborting)\r\r\n'

----------------------------------------------------------------------
```

Also publish the fingerprint of the server ssh key, which addresses this warning in the correct way (I feel) and since we can publish the fingerprint, why not.

/reviewed-on nexedi/slapos!492

Since "stack/monitor: Add auto-restart on certificate-authority section"
certificate authority is correctly exposed in supervisor with its hash.

/reviewed-on nexedi/slapos!500

/reviewed-on nexedi/slapos!499

Remove all references to deprecated directories. The promises inside monitor-directory:promises directory are not run anymore by slapgrid. The scripts inside monitor-directory:reports are not run either.

In this PR, we just update the directory location:
 * promise directory is now etc/promise (${directory:promise})
 * reports directory is now bin (${directory:bin})

/cc @alain.takoudjou @rafael

/reviewed-on !490

so that on first connection clients can check the fingerprint key
instead of blindly accepting it.

This seem to be needed "sometimes", apparently on the first connection
after server is started, but this was not investigated much.

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 !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 !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.

We no enforce formatting of json schema, this was causing a test
failure:
```

======================================================================
FAIL: test_schema_neoppod_instance_neo_input_schema_json_format (slapos.test.test_json_schema.TestJSONSchemaValidation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/slapgrid/slappart0/srv/testnode/bpy/inst/test0-0/parts/slapos.cookbook/slapos/test/test_json_schema.py", line 80, in run
    content.splitlines())
AssertionError: Lists differ: ['{', '  "$schema": "http://js... != ['{', '  "$schema": "http://js...

First differing element 87:
'            "description": "Storage type. Defaults to MySQL if available, else SQLite.",'
'              "description": "Storage type. Defaults to MySQL if available, else SQLite.",'

First list contains 3 additional elements.
First extra element 119:
'  },'

Diff is 5422 characters long. Set self.maxDiff to None to see it.

----------------------------------------------------------------------
```

/reviewed-on nexedi/slapos!482

We still want to check the signature of the reference .data file and of the index

/reviewed-on nexedi/slapos!453