This will be used to run tests using interpreter with pre-installed
eggs, generated with zc.recipe.egg's interpreter

- testnode saves in its config the repositories paths
- minor refactoring and cleanup

/reviewed-on nexedi/erp5!606

- the commands to run the tests are launched using threads
- a thread is used to ask instance for metrics periodically
- refactoring for a more generic code
- refactoring in log handling
- old code related to created documents and create users removed
- new script parameters
- general refactoring and cleanup

- hardcoded software release url removed (http with password protection for now)
- scalability runner handles frontend request. It asks for a local master frontend apache software installation and instance request.
- testsuite brings the urls corresponding to instance, bootstrap, metrics collection.
- vinculation between scalability runner and runScalability script. Process manager is used to run the script as a command.
- scalability runner manages the test result cases and loops among different testsuite configurations.
- userhosts software is used to run the command for the runScalability script, to solve DNS.
- refactoring according to last changes in TaskDistribution
- general refactoring and cleanup

- communicator considers requests of master frontend and instance destruction.
- communicator retrieves frontend related information from instances.
- minor refactoring and code cleanup.

- TestThread runs a target command using a testnode-process-manager
- TestMetricThread makes a get request to a target url periodically and collects the responses

The /bin/ folder of all extra SR provided by the testnode are added to PATH.
SR must fixed either by moving executables or adding symlinks.

The testnode will stop looking at the parameter list of runTestSuite,
and --firefox_bin/--xvfb_bin are deprecated.

This is part of defining a generic and unique API between the testnode and
the tested software.

Conflicts:
	erp5/util/testnode/ProcessManager.py

A lot was found with pylint.

Removed code from not implemented and not needed compatibility layer.

/reviewed-on nexedi/erp5!525

There is no need for any client to call tool directly.

This results with calling correct methods on the server.

The module is to access Distributor not the whole tool.

This results with calling correct methods on the server.

- some method names were changed to make them clearer
- new intermediate class 'SlapOSTester'

- method waitInstance moved from runner to communicator
- new simple methods in communicator for request and wait instance
- new methods to modularize runner code
- communicator initialization code moved in runner

Variable name changed from jsonData to json_data.
Old comment deleted.

Some methods in the slapos master communicator no longer exist. The unit test for scalability was updated accordingly.

An update in zope.testbrowser dropped the mechanize dependency used by the browser. Now it uses WebTest instead.

Details of the update: https://pypi.python.org/pypi/zope.testbrowser/5.2.1

- Most of the communication with slapos master is done using the new Slapos Master Communicator instead of Slapos Controller:
  * supply, request, check instance status, check software status.
- Refactor of related methods (waitInstance, isSoftwareReleaseReady, etc.)
- Initialization of communicator: initialize connection to SlapOS usign key and certificate
- General refactor and cleanup: some unnecesary sentences, comments and methods were removed.

- The base of this code comes from some work done by Rafael in here:
    https://lab.nexedi.com/nexedi/slapos.toolbox/blob/master/slapos/agent/tester.py
- Refactor in communication with slap objects for supply and request.
- Added method to check if instance is requested.
- Refactor in log calls.

In order to safely use non-XML allowed characters coming from various
sources wrap basestring into xmlrpclib.Binary before sending it to the
server.

Firefox and Xvfb aren not provided by the tested SR,
but rather by a separate SR that is installed by the testnode.

Also if process_timeout is available in received configuration setup
process_manager with transmitted value.

Backward compatibility is assured, that if no process_timeout is
provided, nothing is being updated.

Also process_timeout not set on master (the default), will not change
local default.

Since a process might exit by himself at any time, handle exceptions when
we try kill processes