Those alarms read the promise parameters (configured for example by SlapOS) and
can configure ERP5 if user want to solve the difference.

  Read external promise parameters.

  The parameters should be provided by an external configuration file.
  Location of this configuration file is defined in the zope configuration
  file in a product_config named as the path of the ERP5 site.
  Example if the site id is erp5:
    <product-config /erp5>
      promise_path /tmp/promise.cfg
    </product-config>

  The promise configuration is a simple ConfigParser readable file (a list of
  section containing a list of string parameters.

  getPromiseParameter returns None if the parameter isn't found.

This will prevent creating compensation movement if stop date of the open order
line is increased.

This reverts commit 1ec72363.

Do not expand on equal dates too.

Creation and modification dates are not object properties, they are provided by
getter methods and shall be never set directly.

Conflicts:

	product/ERP5/bootstrap/erp5_core/bt/revision

Generate activities and allow to pass the tag. Use search and activate
everywhere which will allow to walk through objects without killing the cluster
even in case of really big documents.

Alarm can generate a lot of activities, so run them less often then critical
ones.

Also minimise activity hurricane by calling expand directly.

Open Orders are searched using indexation timestamp, which allows to see them
in "windows", and does not repeat expand if not needed.

Another way to generate and update simulation shall be found, especially on
busy sites.

Return a safe html selenium test code (which always fails) to indicate a problem when download a test. This will prevent Zelenium get Stalled during the launch.

Follow up commit e0855913

Code cleaned up from not needed variables.