Do not access form submission REQUEST from the listbox list method,
as it is rendered asynchronously in ERP5JS

This reverts commit 35b2c024.

Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

erp5_web_renderjs_ui: keep previous focus color

This reverts commit a87db49b.

Change max age to 1 hour and 1 day

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 nexedi/erp5!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