squash! ERP5Workflow: erp5_configurator_*: Migrate Configurator Workflows from workflow_module to portal_workflow (!1378).

ERP5Workflow: erp5_configurator_*: Migrate Configurator Workflows from workflow_module to portal_workflow (!1378).

This also moves all Configurator Workflows in workflow_module to portal_workflow
(workflow_module was an implementation of Workflows based on ERP5 objects and
not using DCWorkflow code).

* Workflows are now defined on on portal_workflow._chains_by_type anymore but,
  as everything else, on the Portal Type itself.
* portal_workflow can contain and work at the same time with legacy and new
  Workflows (ERP5Type/patches/DCWorkflow.py monkey-patching DCWorkflow classes
  to provide the same API).
* Existing Workflow Scripts should work as they are and the code can be updated
  later on to take advantage of the new API:
  + With legacy implementation Workflow {Scripts,Transitions,Worklists,States}
    were in a Folder ({scripts,transitions,worklists,states} attribute) but
    all of these are now in the Workflow itself and their IDs are prefixed
    (PropertySheet-style), for example `script_`. Legacy attributes are
    provided in new implementation to call the new API.
  + When calling a Workflow Script, `container` was bound to its parent, namely
    WF.scripts (Folder) and a Workflow Script could call another. Now `container`
    is bound to the WF itself and Workflow Scripts are in a Workflow directly.
    New implementation `scripts` attribute handle such use case.
  + Override portal_workflow.__getattr__ so that a Workflow Script can call
    another one without prefix.

erp5_performance_test:testWorkflowPerformance were ran to compare DCWorkflow
and ERP5Workflow implementations and it seems to be about 4% slower with the
new implementation (legacy: 7.547, 7.593, 7.618, 7.59, 7.514 and new: 7.842,
7.723, 7.902, 7.837, 7.875).

Work done by Wenjie Zheng, Isabelle Vallet, Sebastien Robin and myself.

because this business template uses fields from erp5_trade field libraries

These fields were created when proxify action was broken.
This re-exports the fields after using fixConsistency on them.

see also nexedi/erp5!1352

also add rel="noopener noreferrer" for security.

It seems this workfliow was created by copy-pasting event_workflow,
without cleaning these variables up: they are used by a transition dialog
on event_workflow but nothing on this workflow.
Still, they are stored on every single document on every single transition,
wasting resources. So remove them.

erp5_jquery_sheet_editor: unset Accelerated HTTP Cache Manager configuration in intermediate template.

See merge request nexedi/erp5!1385

So different test suites can have a same named sequence without
theme colliding with each other

When installing the tested software failed, no test result lines
have been created, this should have status FAILED.

person reference contained the username, so test was also passing, but what we
really want to test is that the username is in the mail body.

ee64d50c (patches/CookieCrumbler: update patch for CMF 2.3, 2019-09-09)
introduced a NameError, getRequest was not imported.

All reports were properly including movements from the last day,
except general ledger which were only including movements made
without hours:minutes (at midnight). This was not a problem for
manually entered transactions, which are usually made at 00:00
but when transactions are entered with hour:minutes they were
not included.

BMP are not compressed and use more disk space than PNG.
The trick is that ERP5 uses by default a quality of 75% on images ([this is
default on propertysheet]) so we need to dump the image with maximum (100%)
quality.

Update also assertion message to not include the full base64 image in case of
difference, use a short assertion message and save images in log folder.

[this is default on propertysheet]: https://lab.nexedi.com/nexedi/erp5/blob/2f9b67fae3ac59955231d4191a34134ff1b6079a/product/ERP5/bootstrap/erp5_property_sheets/PropertySheetTemplateItem/portal_property_sheets/HtmlStylePreference/preferred_image_quality_property.xml#L56

When rendering reports, deferred style was only keeping request.other, but
some places, like Products.ERP5Form.ListBox.ListBox.getParamDict read only in
request.form, which caused different behaviours when rendering reports
directly or in activities, because when rendering in activities request keys
that the report dialog might have pushed were not preset in request. They
were of course present when rendering the report directly, because this was
the same request, so this lead to different behaviours wether reports were
rendering in activities or directly, like we could observe in 7058ab6f
(accounting: fix grouping option of GL when running in deferred mode, 2021-02-25)

This change deferred style to properly propagate request.other and
request.form in all activities of reports.