In this specific case, the number of grouped messages is bound,
and actually not greater than the number of grouped messages
being processed for normal indexing.

The goal is to make better use of the ZODB Storage cache. It is common to do
processing on a data set in several sequential transactions: in such case, by
continuing execution of these messages on the same node, data is loaded from
ZODB only once. Without this, and if there are many other messages to process,
processing always continue on a random node, causing much more load from ZODB.

To prevent nodes from having too much work to do, or too little compared to
other nodes, this new parameter is only a hint for CMFActivity. It remains
possible for a node to execute a message that was intended for another node.

Before this commit, a processing node selects the first message(s) according to
the following ordering:

  priority, date

and now:

  priority, node_preference, date

where node_preference is:

  -1 -> same node
   0 -> no preferred node
   1 -> another node

The implementation is tricky for 2 reasons:
- MariaDB can't order this way in a single simple query, so we have 1
  subquery for each case, potentially getting 3 times the wanted maximum of
  messages, then order/filter on the resulting union.
- MariaDB also can't filter efficiently messages for other nodes, so the 3rd
  subquery returns messages for any node, potentially duplicating results from
  the first 2 subqueries. This works because they'll be ordered last.
  Unfortunately, this requires extra indices.

In any case, message reservation must be very efficient, or MariaDB deadlocks
quickly happen, and locking an activity table during reservation reduces
parallelism too much.

In addition to better cache efficiency, this new feature can be used as a
workaround for a bug affecting serialiation_tag, causing IntegrityError when
reindexing many new objects. If you have 2 recursive reindexations for both a
document and one of its lines, and if you have so many messages than grouping
is split between these 2 messages, then you end up with 2 nodes indexing the
same line in parallel: for some tables, the pattern DELETE+INSERT conflicts
since InnoDB does not take any lock when deleting a non-existent row.

If you have many activities creating such documents, you can combine with
grouping and appropriate priority to make sure that such pair of messages won't
be executed on different nodes, except maybe at the end (when there's no
document to create anymore; then activity reexecution may be enough).
For example:

  from Products.CMFActivity.ActivityTool import getCurrentNode
  portal.setPlacelessDefaultReindexParameters(
    activate_kw={'node': 'same', 'priority': priority},
    group_id=getCurrentNode())

where `priority` is the same as the activity containing the above code, which
can also use grouping without increasing the probability of IntegrityError.

instead of crashing.

This can happen in workflow if we have:
- transition_x is declared as possible in state_x
- then transition_x gets deleted
In this case in state_x in manage_properties nothing is visible,
which creates an inconsistent in its data, yet functional generally workflow

Since it is easy to create such cases, just ignore them in Module_listWorkflowTransitionItemList
so that mass change state can work

This also fixups b9b14bc7 for the case
where the consumption range is different from consumed budget or engaged
budget (for exemple when we have only engaged movements on a given node).

Until now, only bt5 Extension/Test/Document could be migrated from
filesystem.

From migration dialog, allow to select any Products.ERP5.Document.* (only,
for now) to be migrated. By default, automatically select Products Documents
used by the current bt5 Portal Types (by looking at the mro() of its
erp5.portal_type classes).

Also, to easily identified where it was migrated from, source_reference
is set to 'bt.getTitle():ID' for bt5 Extension/Test/Document and
'Products.ERP5.Document.XXX' for filesystem Products.

One Mixin to handle {Document,Interface,Mixin,Test,Extension} code from:
  * deprecated local (instancehome/XXX).
  * ZODB Components.
  * Products migration (in a later commit).

Kill any process having in command line the path reserved for unit
test. This would really allows to kill any remaining process if any.

Do not look if processes are child of testnode, because processes
like mariadb and others are not running as child

portal.portal_simulation.getInventoryList(section_category='', src__=True)
use query like
AND (`related_stock_section_category_uid_1_category`.`category_uid` = 281(Uid of portal_categories)

Kill any process having in command line the path reserved for unit
test. This would really allows to kill any remaining process if any.

Do not look if processes are child of testnode, because processes
like mariadb and others are not running as child

It was incorrectly assuming style of passed information.

SlapOS will publish directly SQLBENCH_PATH in environment, so
start using it also trusting that PATH is correctly set to find proper perl,
with fetching old OPENSSL_BINARY and finding perl in the old wayas fallback.

otherwise Firefox (with default configuration) may display strange colors, especially if the original uses ICC v4 profile.

Notify the user and redirect to the storage page to force user to enter credentials if needed

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.