Back-porting a patch from upstream's github repository.

This reverts commit 18c4c3e2.

  Reduce a little the path+filename for the socket file, as NGINX/Linux has a limitation for long paths on this instruction.

  This small change allow the resilience test works w/o kernel patches or workarrounds.

Now we can run slaprunner's slapos just with `slapos`

For consistency and because mosh uses $SHELL and otherwise would use the
system shell ( /bin/sh )

~/bin/bash was used sometimes in place of bash, but we can use the
"real" bash directly, not need for a wrapper.

Introduce a section to define the shell $PATH and $SHELL we want to reference
from other sections.

slapos.cookbook:shell recipe creates a wrapper copying environment of
user running slapos node instance, but we are trying to avoid this.

For consistency, we want to use this shell when invoking `bash`

When connecting by ssh, bash starts with a $PATH containing standard
directories (/usr/bin:/bin). We don't want this to have priority either.

This simplifies 17931bed by not
overriding ~/.bashrc (that according to our ~/.bash_profile can be
modified by end users)

Because we have set a $PATH containing mosh-server it can be used with:

$ LC_ALL=C.UTF-8 mosh slapuser0@2001:67c:?:?:?:? --ssh='ssh -p 22222'

shellinabox shell wrapper, bash's .bashrc, gunicorn environment (which
minishell's inherit) and openssh command should all have the same $PATH
for consistency

Only use /usr/bin:/bin/ as a fallback.

Environment of user running `slapos node instance` should not influence the
instance.

Go1.5 and go1.6 are not used anywhere in slapos tree and neither these versions are supported by upstream release policy https://golang.org/doc/devel/release.html#policy anymore. So let's remove them.

/reviewed-on nexedi/slapos!239

This reverts commit 9b0b7a8b

This reverts commit 40108537.

Using the public cloudooo for all unit tests makes things
unreliable, we have every day many tests failing due to this. It
would be required to reapply this change to :
- make ERP5 more resilient to network failures when there is
  issues connecting to cloudooo
- find some automated ways to have a cloudooo per testnode machine,
  with idea of having possibility to request "where is the
  nearest service doing that"
- possibly having a CDN of cloudooo, but this does not prevent having
  a cloudooo per testnode