on very large python files (>1000 lines) sometimes they queue up and we
have to wait for all requests that were queued by zope.

XXX maybe this does not happen when accessing through haproxy/apache, I
am observing this when hitting zope directly

We make it possible to define function the same way it's currently
possible to define accounts. The idea is similar: to be able to use this
information in accounting generation rules.

The typical accounting generation configuration using this will use the
function defined on the supply line if any is defined and with a fallback
to the function defined on business process' trade model path.

For now we don't introduce such configuration by default, but this may
become part of  the configuration generated by configurator some day.

The view of accounting transactions have dynamic columns so that all the
information that matters the most is displayed directly on the "main"
view. This extends the columns to add a column for all the items attached
to accounting movements.

Without these accessors, we have to use constructs like:

    resource.edit(
        default_purchase_supply_line_destination_account='account_module/123'
    )

with the accessors, we can use:

    resource.edit(
        default_purchase_supply_line_destination_account_value=account,
    )

The former is a bit error prone, because typos in the property name
silently create a local propery and typos in the relative URL make a
"broken" relation.

odt_style comes with "Print" global actions which allows getting the
default form as ODT and convert it to selected format and DMS comes with
"Print" actions which return a PDF of the document content.

As a result, when user try to use Print, they have the same action twice
with no way to know which one is which.

This is detected by CodingStyleTestCase.test_DuplicateActions, but only
for configurations where both erp5_odt_style and erp5_dms are installed,
which is not the case in coding style test suite which only install the
miminmal dependent business templates.

Fixes after nexedi/erp5!1451 

With the RAM implementation it was possible to use in session:
 - list or dict of temp documents
 - temp documents created with `newTempBase` ( not just `newContent(temp_object=True, ...)` )

This repairs these two use cases.

See merge request nexedi/erp5!1533

See merge request nexedi/erp5!1532

This is a step to be able to run ERP5 on zope4, where servers are no longer started by ZConfig.

This will be used by nexedi/slapos!1114

See merge request nexedi/erp5!1529

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.

Now that TemporaryDocumentMixin and TempBase implementation details have
been made consistent, there's no reason to duplicate code.

This also make TempBase uses TemporaryDocumentMixin of __setstate__, so
TempBase have more sane behaviour when being pickled.

Products.ERP5Type.mixin.temporary.TemporaryDocumentMixin and
Products.ERP5Type.Base.TempBase implementations were a bit different:

 - getTitle was acquiring title in TemporaryDocumentMixin, although this
 was probably never acquiring in practice because most documents have
 a title.
 - isIndexable was an int and not a PropertyConstantGetter like it is
 supposed to be.

Change TemporaryDocumentMixin to behave like TempBase here.

=

Before f359f267 (Use Distributed Cache for Session, 2021-07-19)
when we were using RAM cache for sessions, it was possible to store
collections (eg. dicts or lists) with reference to ERP5 documents in
session, but after this change, using such collections was refused
with error:

    TypeError: Can't pickle objects in acquisition wrappers.

This change restore the possibility of using collections, by being
more clever when we store and retrieve collections

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.

When running with ZServer, TimerServer will be started by ZConfig
machinery, because ZServer comes with some ZConfig data types for server
factory which start servers.

One Zope 2, ZServer was imported from zopeschema:

https://github.com/zopefoundation/Zope/blob/2.13.30/src/Zope2/Startup/zopeschema.xml#L10

and ZConfig used the TimerServerFactory to create a TimerService.

On Zope 4, ZServer is not imported anymore in the new wsgischema:

https://github.com/zopefoundation/Zope/blob/4.6.3/src/Zope2/Startup/wsgischema.xml

so the ZConfig data type can not be used to create the server.

Instead of relying on ZServer's ZConfig, we create the server directly
from the startup script, the logic to attach to waitress is already here
and startup and factory just called create, so the only difference is
that we no longer use zope.conf to configure TimerService, but configure
from the script.

SlapOS profile also needs to be modified in order to not include ZConfig
bits for timerserver and to pass the timerserver interval in the wrapper
to this script.

Since https://github.com/zopefoundation/Zope/commit/2da2c2c28a8b21e78e8ef93aa17da926e3102c26
SERVER_PORT is assumed to be convertible to int.

The value of this port is not really supposed to be used because
TimerServer requests does not have a server (for example in CMFActivity
we recreate the initial request), so put a value of -1 to prevent
accidental use.

Only catch exceptions, we don't need a bare except here. In case of
exception, log the traceback instead of being silent.

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.