slaprunner: updates export script to make sure that etc directory exists in backup before copying into it

When it is restored on importer instance, it erases its RSA key... Which makes the sshd service to crash

slaprunner: uses sshkeys_authority recipe to manage openssh keys, otherwise they may change at any slapos run

This makes easier the development of the webrunner, as it can be deployed within a webrunner

Changes include:
  * new parameter "no-ipv4-frontend" to prevent the request of an ipv4 frontend. The webrunner cannot provide one, so let's get rid of failing promises.
  * new paramaters to define the ports of the ssh servers (for runner-importer and runner-exporter). Then no colliding when servers run on the same IP.

Revert "slaprunner: fix resiliency test, add development-mode (bool) parameter for easy build webrunner in webrunner"

This reverts commit 59966611.

slaprunner: fix resiliency test, add development-mode (bool) parameter for easy build webrunner in webrunner

fix publish custom frontend url
simplify monitoring connection parameters

so that build will not fail if the directory was left during previous
builds.

@rafael says frontend infrastructure is not yet ready to handle slave
requests for frontends which come with lab.nexedi.com frontend SR URLs.

So revert apache-frontend-URL related part of 86deb9c6 (*: slapos.git
moved to https://lab.nexedi.com/nexedi/slapos.git) back for now.

/cc @jp
/reviewed-by @rafael
/reviewed-on nexedi/slapos!52

86deb9c6 (*: slapos.git moved to https://lab.nexedi.com/nexedi/slapos.git)
went over whole tree and updated slapos.git URL but when changing
non-top-software.cfg-like files forgot to update their md5sum in
software releases.

Fixes started to appear - e.g. 8b1496c3 (kvm: fix md5sum, thanks
@alain.takoudjou), but generally the whole tree remains more-or-less
broken.

Fix it. (not tested - manually checked files and updated md5sums)

/reported-by @rafael

Most Ruby projects are built via Bundler[1], e.g. the upcoming GitLab,
and Bundler supports building/fetching dependency gems in parallel:

    http://bundler.io/v1.10/bundle_install.html#jobs

via using `--jobs <n>` command line option.

All bundler options can be also passed in via environment variable, and
this way we can use BUNDLE_JOBS=<n> for default `--jobs <n>`.

Let's use it, and this way speedup Ruby-related builds (like we already
do for Make- and NumPy- based software).

[1] http://bundler.io/

/cc @jerome, @cedric.leninivin, @kazuhiko

Starting from NumPy 1.10 numpy's distutils support parallel building

    http://docs.scipy.org/doc/numpy/user/install.html#basic-installation
    https://github.com/numpy/numpy/commit/23d54617

and this way software which uses numpy's distutils (scipy,
scikit-learn, etc) should support it too.

Let's use it, like we currently already use MAKEFLAGS for speeding up
make-based projects.

/cc @jerome, @cedric.leninivin, @kazuhiko

Currently we use '%d' and string formatting on max(1, ncpu / cpu-usage-ratio),
because `ncpu / cpu-usage-ratio` is float:

    In [1]: from __future__ import division

    In [2]: 8 / 4
    Out[2]: 2.0

and jinja2 uses future division by default:

    {{ 8 / 4 }}   ->   2.0

We can however make things more explicit, by explicitly using integer
division (// operator) and this way avoid the need for '%d' and string
formatting.

/cc @jerome, @cedric.leninivin

The calculation is full line long, and we are going to reuse this number
in a couple of new places, so this way it makes sense to first compute
jobs number separately, and then reuse the variable.

/cc @jerome, @cedric.leninivin