Tic'ing mid-hot-reindex is not possible, so immediate reindexation is
not avoidable here. Also, immediate indexation of just-created document
is acceptable, so this is not exactly a bad example.

Fixed commit was part of a larger commit stack, and this fix was
mistakenly squashed in an unrelated commit, and hence did not make it to
master.

Intercepting an indexation activity is not reliable, as multiple indexation
activities may have been spawned, and the wrong may be intercepted here.
So instead, explicitly unindex the document intended to not exist in
catalog.

This is a very minimal support, as "flush" is kind of deprecated, only
surviving because tests need to be able to tell which activity may
execute, and there is currently no other way to support this.

Avoids logic duplication on how to store the environment.
Avoids relying on ERP5 products (for whatever it's worth anyway).

Also, simplify docstring.

Only PluggableAuthService import may not be importable, and is decisive
in importing from ERP5Security, which must then work.

Just like age is taken into account inside each activity queue.

Increasing priority value (hence making the activity execution priority
lower) means that all previously-spawned activities will have at least
started execution before the next batch of activities begins being
prepared. During that preparation, more activities will end, meaning there
is then unused processing node time, decreasing processing efficiency.

By making re-call activity have the same priority as spawned activities
will reduce this delay by making the re-call activity candidate for
execution at the same time as the latest activity batch, without leading
to activity queue size increase: older activities within a given priority
range still get precedence, so any older group will tend to finish before
more batches get spawned.

Measures on indexing 700k documents with 20 activity nodes:
- priority + 1: 84k documents indexed in the first 5 minutes,
  47k in the last 5 minutes. Average: 64k/5 minutes
- priority: 101k documents indexed in the first 5 minutes,
  97k in the last 5 minutes. Average: 99k/5 minutes
Peak speed (which is the initial speed) is 20% higher.
As the slowdown rate (likely coming from lower-priority activities piling
up in the message_queue table) is also much lower in the second case
(900 fewer documents indexed on each 5 minutes increment instead of 4k),
the overall average speed improves by 54%.

fckeditor is clever enough to render the content, properly isolated from the main web page

/reviewed-on !565

It is usable for activity nodes where we need activity processing (i.e.
tic) to happen much faster that normally (default is 5 seconds).

It has been successfully used in a production system for months (and big dev instance)  despite not done in generic line now proposed.

@nexedi , any objections for not having this in a generic ERP5's timerservice?

/reviewed-on !562

Maybe @kazuhiko  is interested in this since you are using the edit_xmlrpc methods sometimes in your tests, right?

This effectively allows to zero-out some TALES expressions via manage_tales_xmlrpc which was not possible before. It is enough to set them to an empty string. 

/reviewed-on !563

[renderjs_ui] Extract utility function ensureArray, getFirstNonEmpty, and isEmpty into global gadget

/reviewed-on !570

This will increase the information's density for desktop users

-  use field defined CSS class on the top-level div only
-  compute correct paddings for horizontal elements

/reviewed-on !566

Iframe are only used with the editors, which now have a maximize feature

Add Base_renderForm to bypass erp5_hal_json_style limitations: it is not possible to render a field in JSON by directly using it as a callable.

[erp5_crm_renderjs_ui_test] Test create response dialog

This will prevent the input gadget to be changed if its parent call render with the same value (as ERP5 does in case of formulator error).

Display the update button if an action is defined.
Send the 'update_method' in the query in this case.