- declare a service
- use jquery ui dialog instead of jquery mobile
- use erp5 data format for render / getContent

BUG Jsplumb silently swallows exceptions on handlers

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