~/bin/slapos script does not overwrite $SLAPOS_CONFIGURATION if it's set,
to prevent service accidentally use another slapos.cfg if $SLAPOS_CONFIGURATION
is set for some reason, explicit pass the path of the slapos.cfg

It seems `eclint fix folder/file` sometimes dos not work, but `eclint
fix folder/` worked.

done with:

     npm install
     git ls-files | grep -v '\/unstable\/' | xargs ./node_modules/.bin/eclint fix
     git ls-files | grep buildout.hash.cfg | xargs ./update-hash

fixup of 6fbc6e15

  This allow slaprunner call the API more easily.

   This would allow the webrunner invoke it to bootstrap the instance
   rather them create the folders manually.

  Creating this file and updating the slapos.cfg configuration
  is possible to call slapos node format from the partition in the
  same way you would do in a computer.

TODO: There are still direct references to specific version of Python in:
  - slapos component
  - bazel templates
  - nextcloud & theia SR

This was broken in 8725ab1a.

fix the way of getting parameters in the new recipe.

When we have a section to generate a python interpreter with eggs built
in, don't name this `extra-eggs` because the meaning is not clear.

See commit 1e514399.

The fixes a conflict with 'runner-exporter' due bugs in cns.recipe.symlink

Anyway, a much better idea would be to add ~/software_release/bin to PATH.

  This means the user don't have any instance at this point.

collective.recipe.shelloutput does not work well with Python 3: it
outputs values as bytes, which are printed in the format "!py!b'XXX'".

The new "init" option is used as a replacement.

We need to access six when calling the 'replicated.replicate' macro.

"max" and "int" became directly accessible in slapos.recipe.template.

These keys are not managed by trust of a certificate authority, just by
"trust of first use" so it does not make sense to use a key authority.

This also cause difficulties to publish the key fingerprint as a
parameter, because we can't get the key fingerprint until the authority
service is started.

Also enable ecdsa key.

This fixes random failures with slaprunner tests, because the published
fingerprint was never correct on first buildout run.

Existing webrunners will have a new ssh host key after this.

This reverts commit dcd2f8d6.

It has to be redone with proper test coverage.

Since the introduction of shared parts, there is no guarantee about
the location of sqlite3 binary.

In test nodes we put the software_root folder out of the webrunner so we
can keep it for the following tests. Except that the shared folder has
been introduced by default recently, and it is still inside the webrunner.

Thus, between 2 tests the webrunner is deleted, so the shared parts are too,
but not the SR folder (which is marked as completed). Then in the successive tests
the software release fails to build, or the insances fail to isntanciate.

In 95c05120, a published parameter "ssh-url" was added
to the webrunner, clashing with the existing "ssh-url" parameter used by the resilient
stack (which is extended by webrunner).
As the new "ssh-url" is public and read by customers, it doesn't make sense to rename
it to something more slaprunner-ished, more especially it already existis "ssh-command",
so if a second parameter was named "runner-ssh-url" it wouldn't make sense to the user...

This change had to be propagated to all the software releases extending the resilient stack.

Finally, I think that stacks should use namespaces to avoid conflicts with the software
releases extending them. Currently, we are doing the opposite and are using namespaces
for software release to avoid conflicting with their stack : for exemple, in stack/resilient
we have a section [sshd-raw-server] and in the software/slaprunner we have [runner-sshd-raw-server].
This situation will create clashes when one software release extends 2 stacks, as nothing
guarantees that 2 stacks have no conflicting section name, config file path, ...

If slaprunner itself was installed on a slapos which had shared parts
enabled, these shared parts will also be used while installing softwares
inside the slaprunner.

Because ${buildout:shared-part-list} is a multi line property, it was
not possible to generate .cfg files (which needs special handling of
multi-line strings) directly from software buildout (where jinja
templates are not yet available), so we use a trick of generating a
plain text file in software and parsing it during instance.

Instead of having to copy and paste the "ssh command", having a
clickable link is more user friendly. This integrates seamlessly with
ChromeOS secure shell app (eventhough the app does not do anything with
fingerprint as per version 0.19)

Because this slapos often is executed when just running `slapos` at is
in the $PATH, we should also consider special cases where users want to
call this script with another $SLAPOS_CONFIGURATION.

When $SLAPOS_CONFIGURATION is already set, ~/bin/slapos will not change
it, it will only set it when not set.

Because slaprunner might be instanciated in a different directory than
the shell user $HOME (like in recursive SlapOS), it's necessary to set
HOME to the base directory. For "bare metal" SlapOS, this would not make
any difference.