Proftpd with sftp and virtual users

http://www.proftpd.org/docs/

# Features

 * sftp only is enabled
 * partially uploadloaded are not visible thanks to [`HiddenStores`](http://proftpd.org/docs/directives/linked/config_ref_HiddenStores.html) ( in fact they are, but name starts with `.` )
 * 5 failed login attempts will cause the host to be temporary banned


# TODO

 * only password login is enabled. enabling [`SFTPAuthorizedUserKeys`](http://www.proftpd.org/docs/contrib/mod_sftp.html#SFTPAuthorizedUserKeys) seems to break password only login
 * log rotation
 * make sure SFTPLog is useful (seems very verbose and does not contain more than stdout)
 * make it easier to manage users ( using `mod_auth_web` against an ERP5 endpoint or accepting a list of user/password as instance parameter )
 * allow configuring webhooks when new file is uploaded



----

depends on slapos.core!41

/reviewed-on !311

_ (underscore) is not supported by apache as domain name
(https://bugzilla.redhat.com/show_bug.cgi?id=1410130), so avoid using it.

/reviewed-on !320

The build of nodejs uses python, and python leaking from the system can lead
to unexpected results, thus use provided from SlapOS.

/reviewed-on !319

The correct is use require and not required.

fix getInstanceParameterDict typo

/reviewed-by: TrustMe

To run tests from software/proftpd/test

To run tests locally by `python setup.py test`

This is a new kind of test suite that compile software, request instance
with specific parameters and check that the instance works as expected.

@alain, @rafael 

Test is here: https://nexedi.erp5.net/test_result_module/20180412-3688F368/2/view

Its failures which are different from  master one (https://nexedi.erp5.net/test_result_module/20180412-3501D1A/1) seems unrelated to my changes thus I propose to emrge it in and include in next webrunner release.

/reviewed-on !317

This reverts commit 1bdac5da.

This commit breaks webrunner resilience importer. This is not the proper fix

Because of this: https://lab.nexedi.com/nexedi/slapos.core/blob/master/slapos/grid/promise/generic.py#L44

When slapgrid run promises, it now save promise logs. Thus we need to logrotate them.
Thanks @Alain.

This recipe will be used to generate promise in etc/plugin dir. It solve the problem of promise eggs
dependencies and allow to set custom parameter to use in promise.

The generated script will looks like:

    import sys
    sys.path[0:0] = [
      ...
    ]

    extra_config_dict = {
      'KEY': 'VALUE'
    }

    CONTENT

CONTENT is a python code, the expected content looks like:

    from namespace.module import RunPromise

then the promise section in buildout will be something like:

    [my-promise]
    recipe = slapos.cookbook:promise.plugin
    eggs =
      NAME
      ...
    output = OUTPUT
    content =
      from namespace.module import RunPromise

    config-KEY = VALUE

Instead of having running test installing eggs with setuptools during `python setup.py test`, which fails for `caucase` because one of its dependency (namely `cryptography`) cannot be installed so easily, we want to install the dependencies via buildout, using the same installation methods than in the actual software profiles using our eggs.

What I initially believed would be a small change turned out to be a long journey, especially because of using a develop version of `slapos.recipe.cmmi` caused signature changes in the parts installed by this recipe ( `git`, `openssl` etc - some parts that takes a bit of time to install ) so I had to fight with the software being reinstalled each time. Even though the cases which leads to reinstallation are understood (this even involved fixing a bug in buildout slapos.buildout!14 ), this is still the case. Some solutions are proposed in the commit message of f4b6eeda , but this reached a state where we can consider first merging with this known problem or discuss ways of improving that before merging if it's considered as blocking. Current state is that it takes one hour to re-install what has to be reinstalled and run the test suite on test runner.

Despite this issue, this approach already improve things, because:
 * `caucase` tests are running (and passing)
 * some `slapos.cookbook` are improved so that they reuse eggs from the buildout and do not install again eggs when the are run.
 *  ... and some other small cleanups

This depends on erp5!619 on the `erp5.util` side.

/reviewed-on !309

This function factorize the code to instanciate a recipe in a fake
buildout.
The new feature is that if running in a buildout directory, the recipe
will reuse the eggs from this buildout instead of trying to install eggs
again.