!6 rebased and in a big
commit so that we can start using that
SimulationTool: implement "linear" flow API

testInventoryAPI: silent pyflakes warnings

more interpolation implementation

inventory_list interpolation flow: support at_date & to_date

more and more interpolation API

interpolation

interpolation

group_by_time_sequence_list

testInventoryAPI: move inventory valuation methods in a dedicated test class

This should not be in test inventory list.

test: move Tracking API to a dedicated test module

inventory api: dirty way of disabling cache if keys such as node_category are used.

interpolation: security on SimulationTool_zGetInterpolationMethod

SimulationTool_zGetInterpolationMethod is called in restricted context
of Resource_zGetMovementHistoryList so it needs to be usable by
anonymous.

ZSQL Method does not read parameters from REQUEST, so it looks safe.

inventory_api: rely on catalog to add slot_index in the query

instead of implementing this logic in ZSQL's DTML

cf 2c54e0f5

because Domain.getRelativeUrl (and Category.getRelativeUrl) cannot be
restrictedTraverse'd

This reverts commit cfa272321aa8478583ed339b17913ab428d7207f.

When using checkPythonSourceCode integrated in the source code editor,
for a scenario where developer edit a component and save we can benefit
from caching the check message for the source code content, because the
same check that the one happening in the editor will happen when the
component is saved.

This cache varies on:
 - "component_packages" cache cookie which is reset every time some
component code is edited.
 - zope startup time to take into account editions of file system code.
This assumes that after reseting file system code zope will be
restarted.
 - portal_type, because the checks performed by this function also
depend on portal type.

this makes completions works when using Ctrl+space

This makes "Format Document" / "Format Selection" work.

because pylint is a bit slow on large components, debounce every 2
seconds. TODO: this is too slow.

For now this is just the portal_url, but I'm thinking it could be a
proper tool.

IIRC the only thing needed is that ERP5TypeTestCase.getPortal is an
ERP5Site

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 ...)