This fixes the issue that a transaction with many big messages failed to
commit. By dynamically find the maximum allowed size of a query, it also
speeds up insertion by minimizing the number of queries.

This moves the remaining DTML queries to Python, dropping the 'activity' skin.

Dealing with conflicts of uids is easier if the inserted uids are consecutive:
now, only 1 random value is generated, as base uid. This also preserves the
order of insertion, which is wanted for performance reasons:
- No more random write in the primary index.
- When modifying several lines of several documents, 1 document being processed
  at a time, we'd like that any grouped activity (usually indexation) follows
  the same order, so that a processing node prefer many lines from a few
  documents instead of mixing lines from too many documents at the same time.
  This is usually better for caches.

Average age of activities is dropped because it would become
too complicated to implement and it's useless information.

The original goal was to improve performance by removing the
`processing_node_processing` index and the queries that modified
these 2 useless columns.

The root call to getExecutableMessageList (i.e. the one from distribute)
is fast enough and won't hold old revisions of the database for too long.
It is also completely read-only so it won't lock anything.

This caused useless communication with the server.

As shown in the following example, on a big catalog table,
MariaDB is able to use several indices at the same time
('...' are obfuscated unique values):

  > analyze select SQL_NO_CACHE uid, relative_url from catalog where reference='...' OR relative_url='...';
  +------+-------------+---------+-------------+------------------------+------------------------+---------+------+------+--------+----------+------------+--------------------------------------------------+
  | id   | select_type | table   | type        | possible_keys          | key                    | key_len | ref  | rows | r_rows | filtered | r_filtered | Extra                                            |
  +------+-------------+---------+-------------+------------------------+------------------------+---------+------+------+--------+----------+------------+--------------------------------------------------+
  |    1 | SIMPLE      | catalog | index_merge | Reference,relative_url | Reference,relative_url | 768,767 | NULL |    2 |   2.00 |   100.00 |     100.00 | Using union(Reference,relative_url); Using where |
  +------+-------------+---------+-------------+------------------------+------------------------+---------+------+------+--------+----------+------------+--------------------------------------------------+
  1 row in set (0.00 sec)

So mixing different dependency types with OR should be fine
(no need to split into more subqueries and join with UNION).

This fixes:

  Traceback (innermost last):
    Module Products.CMFActivity.ActivityTool, line 1373, in invokeGroup
      traverse(method_id)(expanded_object_list)
    Module Products.ERP5Catalog.CatalogTool, line 946, in catalogObjectList
      super(CatalogTool, self).catalogObjectList(tmp_object_list, **m.kw)
    Module Products.ZSQLCatalog.ZSQLCatalog, line 813, in catalogObjectList
      **kw
  TypeError: catalogObjectList() got an unexpected keyword argument 'group_id'

/reviewed-on nexedi/erp5!819

* Set MAKEFLAGS with -l to limit number of jobs by load and number of
processes
* set NPY_NUM_BUILD_JOBS & BUNDLE_JOBS to `node_quantity` instance
parameter

/reviewed-on nexedi/erp5!809

Originally, uids somehow sorted messages by date of insertion, in particular
for those that were created within the same second. But since random uids,
such messages became validated or processed in random order.

Note however that by default, messages created in the same transaction all have
exactly the same date, so commit a42da4de
("CMFActivity: Do not use offset for scanning messages to validate.")
forces us to keep the ordering on uids (in addition to priority/date).

Existing instances will upgrade automatically, using the already existing code
to upgrade tables in a generic way. You should see the following logs:

    INFO CMFActivity 'message_queue' table upgraded
    ALTER TABLE message_queue
      MODIFY COLUMN date datetime(6) NOT NULL AFTER uid,
      MODIFY COLUMN processing_date datetime(6) DEFAULT NULL AFTER processing
    INFO CMFActivity 'message_job' table upgraded
    ALTER TABLE message_job
      MODIFY COLUMN date datetime(6) NOT NULL AFTER uid,
      MODIFY COLUMN processing_date datetime(6) DEFAULT NULL AFTER processing
    INFO CMFActivity 'message' table upgraded
    ALTER TABLE message
      MODIFY COLUMN date datetime(6) NOT NULL AFTER uid,
      MODIFY COLUMN processing_date datetime(6) DEFAULT NULL AFTER processing


/reviewed-on nexedi/erp5!820

so that options are kept

Same behaviour than xhtml style

Next step is to activate more contextual listbox actions.

Move listbox select button to the right, to simplify cancellation.

WebSite redirection must be tested against different virtual host monster configuration
TODO: No idea how to fetch the ipv6 in live test

https://lab.nexedi.com/nexedi/slapos/tree/master/software/proftpd/test
was just named "test", we want the test result to be named "proftpd"
instead.

/reviewed-on nexedi/erp5!815

See nexedi/erp5@04939506

Since recent rework of isSubtreeIndexable, direct indexation of a trash bin
is fixed, but recursive indexation recursion condition broke: it stop just
above the trash bin instead of stopping just below it.

Revert "mark file uploading tests as expected failure." as these Functional Tests are not supposed to fail.

This reverts commit ade16831.

enablePrivilege, and thus UniversalFileRead used to upload files, was disabled
in Firefox 17. Since SlapOS Firefox has been upgraded, "The operation is insecure"
error is raised when uploading files. However, this doesn't mean that these tests
should be expected to fail (and if they are, they should be removed instead).

This workflow involved an Assignee who can open, close, re-open and an
Assignor who can close definitively.
This is usually configured so that accountants are Assignee and CFO is
Assignor.

We realized that re-opening a Period that was previously closed is
something we don't want the accountants to do without CFO's approval.

To support this configuration, we only allow Assignor to re-open.

Now Assignee can open and close temporarily and Assignor can re-open and
close definitively.

/reviewed-on nexedi/erp5!813

This is really a hack, which may be integrated into renderJS directly

Reduce potential Zelenium test timeout by waiting for iframe to be loaded one by one

This check got lost when the first isSubtreeIndexable call was done on
parent document and not on self.

This partially reverts:

commit 76e3c115
Author: Vincent Pelletier <vincent@nexedi.com>
Date:   Mon Dec 10 16:40:48 2018 +0900

    Base: Fix isAncestryIndexable implementation.

as it accidentally carried over a totally unrelated (and unfinished)
change.

Start checking isSubtreeIndexable on parent document, not on current
document.
This bug broke Trash Bins indexation (and should not affect anything else,
as only Trash Bins prevent content indexation currently).

Extent trash tool unit test to verify actual indexation, and not just
indexability API.

Fixup nexedi/erp5@559c5e8b

See nexedi/erp5@994d8369

/reviewed-on !768