The new workflow implementation from df85ef46 (ERP5Workflow: DC Workflows
are now ERP5 objects (!1378)., 2020-11-18) had a different behavior in
the implementation of _executeTransition, it was setting all kwargs
from the transition in REQUEST. The reasons for this are unclear, it
seem to come from the first Workflow implementation, 81784db4 (Initial
Import of ERP5Workflow porduct., 2010-10-15)

The side effects are that calling a workflow method, for example:

  document.edit(key=value)

would also alter the global request to set key=value in REQUEST, for the
rest of the current request.

It was causing subtle issues, especially in tests where the REQUEST
lifetime is long.

This was redirecting with the full list of updated documents URLs,
causing too long URLs.

This also simplifies code a bit, change the wording of messages and
use translation.

no need to create temp objects because anyway the transaction is aborted
at the end of each test.
This solve a problem that some APIs behave differently on temp objects
and we don't really have use cases where we use actions on temp objects.

For reference, the case which fail is an action with a TALES condition
using a related accessor, the exact condition was:

    python: object.getAggregateRelated(portal_type="Implicit Item Movement") is not None

This was not patching the right place (I should have used mock ...)

See merge request !1531

The portal types using this form are all PresencePeriod or subclasses,
so use PresencePeriod as a prefix.

TaskMovement_getSimulationStateColorText was same content and calendar
depends on project

Rename Orgnaisation_generatePlanningDomain to Organisation_generatePlanningDomain

also rewrite a sorted to use key instead of cmp

by calling proxy_field.checkConsistency(fixit=True) on them

This tic call has a lot of activities to process. Checking test result
history over the last 2 months, the whole test runtime is mostly under
800s, but with a handful of spikes around 1600s, with one at 2300s. So
pick just slightly more than the worst over 2 months.

Also revert related fixup commits:
  "CMFActivity: fixup do not loop on tic if the node is the distribution node"
  "Products.ERP5Type.tests: Follow-up on ActivityTool.tic signature change."

While the original commit did improve the specific workload it was
designed to improve, it turned out to degrade too much intensive activity
workloads, like initial ERP5 site creation and tests (which, for the
purposes of this change, are the same as a single-zope instance).
Given how easy it is to get a multi-Zope instance, which would solve the
original issue and also provide the better performance necessary anyway
for an instance managing a non-trivial amount of documents, I choose to
revert this change.

I am not reverting several loosely-related changes I applied, which
rather fix real bugs uncovered by the different activity execution
scheme this change provided, especially by letting tests'
"stop_condition" callback being executed a lot more often between
activities, uncovering missing dependencies and unrealistic test
expectations, whose fixes should be beneficial independently from the
reverted code.

This reverts commit 4dfafbc9.
This reverts commit 4eb26017.
This reverts commit 041642d0.

Products.ERP5Security.test.testERP5Security: Fix TestMigration.test_DuplicateUserIdPreventionDuringMigration scope.

For realism: the goal of this exception is to prevent duplicate, and it
relies on the exception triggering a rollback in the transaction manager
(like any transaction error).
Also, use "any()" rather than building entire lists just to check for non-
emptiness.

Person and ERP5 Login documents must be indexed before
ERP5Site_disableERP5UserManager may run, so set the migration tag on these
indexation activities.

Several tests are failing on test nodes with the chosen 100s timeout.
Increase it to 10 minutes. Longer, more exceptional, calls may benefit
from exposing this delay as a tic argument.

Consistently with the Selenium timeout increase.

Products.ERP5Type.tests.ProcessingNodeTestCase: Make tic independent from the number of activities processed per tic.

That number was vastly decreased, causing tests to bail with "tic is
looping forever" for no good reason.
Convert such logic into a deadline one.

Ownership and Owner role are distinct: catalog's "viewable_owner" is
role-based, but "owner" is ownership based. As permissions are applied by
catalog in addition to any given parameter, this should not change the
result of this query. And as any owner which does not have the Owner role
would cause this script to fail on the assertion, this should not change
the result of this script in any way besides avoiding AssertionErrors.

Also, reindex modified documents, as ownership and Owner role are
present in catalog.

See merge request nexedi/erp5!1528

- image editor
- web table editor

- text editor
- slide editor
- svg editor
- javascript editor
- pdf viewer

erp5_ui_test_core: Make waitForActivities independent from the number of activities processed per tic.

That number was vastly decreased, causing UI tests to bail with "tic is
looping forever" for no good reason.
Convert such logic into a deadline one.

This is intended to replace portal_workflow.doActionFor with edit_action,
which was only available for users with modify portal content permission
on the document and also is a bit low level.

It is a common, especially in project specific code that we use
edit_action to leave notes in history and provide better traceability
and we sometimes do this on documents where user does not have the
modify portal content permission.

We don't need Permissions.ModifyPortalContent, Permissions.AccessContentsInformation
is enough. This is consistent with the security declarations in Base and
Folder.

https://lab.nexedi.com/nexedi/erp5/blob/08be2f8cc936fbdc3d5bafb4355c3a475198abc1/product/ERP5Type/Base.py#L2632

https://lab.nexedi.com/nexedi/erp5/blob/08be2f8cc936fbdc3d5bafb4355c3a475198abc1/product/ERP5Type/Core/Folder.py#L1434

I did not identify this monkey-patch.

- Ignore node preference when spawning activities.
  Otherwise, activities which are not spawned with a preferred node will
  get an effective priority penalty compared to same-priority activities
  spawned *with* a node preference, despite both being to execute by the
  same processing node.
- Break activity processing loop when the current processing node is also
  the activity validation node.
  This avoids pathological cases of activity accumulation, for example when
  reindexing an entire site: _recurseCallMethod is spawned in
  processing_node=0, but immediateReindexObject is spawned in
  processing_node=-1 because of serialization_tag dependency, so with such
  loop _recurseCallMethod will be executed over and over, piling indexation
  activities up until _recurseCallMethod does not self-respawn.
  In turn, such activity accumulation lead to an increased overhead, and
  decreased activity processing efficiency.
  This may also allow multi-node instances to more reliably use the
  validation node as a processing node.

The cost for multi-node instances of these changes should be absolutely
minimal (no extra IO necessary, minimal extra code).
A possible drawback on single-node instances is that tic period may become
more important because process_timer will return more often.

If one callable has the default ID '1', it will break nearly all newContent calls on empty object