- it is gowork that is now used by Go-related bits in SlapOS, so using
  gowork is preferred as example. Besides we need gowork to be able to
  use any third-party Go package.

- other languages can use helloweb repository from under gowork/ tree as
  well.

The hash of helloweb.git is changed, becuase its layout had to be too
adjusted to match gowork mode:

nexedi/helloweb@a072af78...8bfedac6

To pick up Python3 support.

nexedi/helloweb@39fd89a3...a072af78

Don't drop support for Go1.9, as, even though Go1.9 is no longer
supported, software/gitlab depends on it.

Our Go1.10.X is also too outdated, but I'm not touching it here neither.

/cc @alain.takoudjou, @luke

	2019-01-21 17:56:18 slapos[13553] INFO While:
	2019-01-21 17:56:18 slapos[13553] INFO   Installing.
	2019-01-21 17:56:18 slapos[13553] INFO   Getting section instance-profile.
	2019-01-21 17:56:18 slapos[13553] INFO   Initializing section instance-profile.
	2019-01-21 17:56:18 slapos[13553] INFO   Installing recipe slapos.recipe.template.
	2019-01-21 17:56:18 slapos[13553] INFO   Getting distribution for 'slapos.recipe.template'.
	2019-01-21 17:56:18 slapos[13553] INFO Error: Picked: slapos.recipe.template = 4.3
	2019-01-21 17:56:19 slapos[13553] ERROR Failed to run buildout profile in directory '/srv/slapgrid/slappart7/srv/runner/software/19771f7b751ffc2a88162b15750c6069'

	2019-01-21 18:01:21 slapos[26771] INFO While:
	2019-01-21 18:01:21 slapos[26771] INFO   Installing.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting section helloweb-ruby.
	2019-01-21 18:01:21 slapos[26771] INFO   Initializing section helloweb-ruby.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting option helloweb-ruby:input.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting section helloweb-ruby-bundle.
	2019-01-21 18:01:21 slapos[26771] INFO   Initializing section helloweb-ruby-bundle.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting option helloweb-ruby-bundle:make-targets.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting section bundler.
	2019-01-21 18:01:21 slapos[26771] INFO   Initializing section bundler.
	2019-01-21 18:01:21 slapos[26771] INFO   Installing recipe rubygemsrecipe.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting distribution for 'rubygemsrecipe'.
	2019-01-21 18:01:21 slapos[26771] INFO Error: Picked: rubygemsrecipe = 0.2.2+slapos001

Ruby stuff was failing to download at all -> let's use the versions that
are the same as currently used in software/gitlab.

Based on patch by @romain.
Helped by @jerome.

openss1.1 caused problems with bundler:

Unable to require openssl, install OpenSSL and rebuild ruby (preferred)
or use non-HTTPS sources

One of solutions for random 502 errors from caddy is to fully disable
HTTP2 protocol ( https://github.com/mholt/caddy/issues/1080 )

We run Caddy with HTTP2 enabled by default, as we can enable/disable it per
each slave, but in some environments it might be just better to fully avoid
HTTP2 codepaths in Caddy.

/reviewed-on nexedi/slapos!495

The IP used by frontend can be different than the real endpoint, and unknown
for the frontend itself, so make it catch-all to allow access.

/reviewed-on nexedi/slapos!497

Because of misleading tests (Accept-Encoding with gzip was always set by
requests, fixed in "caddy-frontend/test: Workaround requests issue with
Accept-Encoding") the original commit "Fix/caddy frontend prefer gzip type
zope" did not really fixed the issue for type:zope backend.

requests set Accept-Encoding header, but in the testr environment we
want to have full control over its behaviour, thus not setting any header if
not really wanted.

As there is not known way to avoid setting the header (skip_accept_encoding is
internal to httplib) set dummy Accept-Encoding header, which is enough for our
environment.

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 nexedi/slapos!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 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 slapos.core!76

/reviewed-on !483

/reviewed-on !489

/reviewed-on !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