... this tool is used to update categories from spreadsheet

Uses graph editor component from DREAM simulation project http://dream-simulation.eu/

This editor is in early stage; it supports edition of business paths from business process and edition of workflow layout in DCWorkflow.

Known problems / TODO:
 - DCWorkflow editor only saves the graph layout and does not allow designing the workflow
 - DCWorkflow graph has to be enabled in history tab for history visualisation
 - rendering of fields in the property edition dialog is extremely slow
 - mixin_promise.js have to be merged. Other TODO's in test.js and jsplumb.js. Generally speaking, this javascript code is poor quality

For the new GroupedMessage class in commit
da234001, I renamed 'obj' to 'object'
at the last minute and I missed 2 occurrences.

The problem with callMethodOnObjectList is that when an object can't be
processed, all other objects of the same group fail without any chance to
be retried separately.

Grouping is configurable with usual CMFActivity parameters in new 'group_kw'
parameter, to avoid any conflict with catalog parameters (**kw).
'packet_size' and 'activity_count' are still accepted for backward
compatibility.

The recent API change was not enough.
A grouping method may need more information: in particular, the dummy grouping
method must be fixed to change user.

This moves much duplicated code to main()
and _ZodbTestComponentBootstrapOnly is changed to also search for BT in
subfolders, like in ERP5TypeTestCaseMixin._getBTPathAndIdList

Suppport ~ also in VCS tab. Not working in current slapos instance that set $HOME to something completely different

There was problems handling '\' and '`' characters.

This was initially set to 'Infinity' to allow browser search but this make the
editor completely unusable with big files.

Installation was working fine because Skin Folder are not ERP5 object but when
updating the bt5, it failed because Folder objects are saved as Trash Folder
(ERP5 object).

Signed-off-by: Jérome Perrin <jerome@nexedi.com>

When grouped messages fail, ActivityTool must distinguish 3 groups,
in order to reexecute them separately, as follows:
- first, those that succeeded
- then, those that were skipped
- at last, failed ones

Grouping methods are updated to handle partial failures, and stop doing
anything when something goes wrong.

Without this, we would have the following pathological cases.

1. Let's suppose first that skipped messages are marked as succeeded.

The problem is that each skipped message that will fail causes the reexecution
of those that didn't fail.

Exemple: A:ok B:ok C:err D:err E:err F:err
  1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
  2: A:ok, B:ok, D:err, E:skipped, F:skipped
  3: A:ok, B:ok, E:err, F:skipped
  4: A:ok, B:ok, F:err
  5: A:ok, B:ok -> commit

And worst, the first failed (C) may be processable again before 5, entering
a failing loop if it is executed again in the same group as A & B.

2. Another implementation is to mark all skipped as failed.

Example:
  1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
  2: A:ok, B:ok -> commit
  3: C:err, D:skipped, E:skipped, F:skipped
 >3: same as 3

=> D, E or F are never tried.

This tweaks retry delays as follows (seconds):

        ConflictError  other failures (K = 1 + retry², with retry >= 0)
before     30             15 * K
after      15             30 * K

Today, bigger delays in case of errors should not be an issue because the
quality of ERP5 has improved a lot and normal code should not rely anymore on
this.

We also don't want to lower ConflictError delay too much, because this
increase the probability of conflicts.

This will be required to improve invokeGroup, in case that a message fails.
We'd like that:
- successful messages are retried immediately
- skipped messages are retried next, and separately
- at last, failed messages are retried, also separately

increasing Localizer weight significantly without limit.