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

what we usually call float is called number in json schema
https://spacetelescope.github.io/understanding-json-schema/reference/numeric.html#number

Test will fail if /tmp/instance_test_resourcefile already exists

All tests from `slapos.test.recipe` module were executed twice since f8de4cc4  when running as `python setup.py test`


`python setup.py test --test-suite slapos.test.test_recipe.additional_tests` still runs only tests for recipes and `python setup.py test` runs tests for recipe and static tests for software releases (for now json schema).

@rafael @katomaso 

/reviewed-on !234

I have been facing some gunicorn issues while fixing tickets. The gunicorn fails start because the pid has been taken by some other process.
This bug has been solved in the v19.7.0.
See: https://github.com/benoitc/gunicorn/blob/master/gunicorn/pidfile.py#L75
Also See: https://github.com/benoitc/gunicorn/releases/tag/19.7.0

Almsost a year ago Nicolas fixed the version of gunicorn to v19.4.5 here 391b026e
Since then the bug stoping up from upgrading has been fixed as well.

/reviewed-on !228

Without logs of SlapOS it is hard to understand the problem in case of
failure, thus add part of this information into log file.