After df85ef46 (ERP5Workflow: DC Workflows are now ERP5 objects (!1378).,
2020-11-18) we increased the expected value from 24 to 36, because it
was just different with new workflow implementation and what was important
is to have large buckets.

After that, the test was flaky and eventually we changed the assertion
from checking that the value equal the expected value to checking that
it's larger to checking that it's larger to a satisfying value and we
used the initial 24 for satisfying value.

A large value here means the bucket contain many items, which happens
when the pickle size is small

We now understand that pickle are short when the pickler was able to
deduplicate some strings because they were the same instances (as
compared by `is` operator). Note that this deduplication happens before
the one operated by Products.ERP5Type.Workflow.dedupStrings after bucket
rotation, it's the "normal" deduplication from pickle happening when
element are added to list.

Because it's a good thing for disk usage to have small pickles, we raise
our expectation and increase the expected minimal value to be 30.

Because error_message variable was missing in component_validation_workflow,
once the validation was refused for an error, every subsequent entry
in workflow history was carrying the same error message.

Adding the missing variable fix this, but it would cause diff every time
we modify and re-export a component, so we also take care of not exporting
it in business template, like we already did for other several variables.

Avoid repeating processing_node condition for every single activity
whose serialization_tag dependency is being checked. This reduces the
length and execution complexity of produced SQL.

The meaning of empty items for **multi** list fields for categories is
not clear for dialogs (if user does not want to apply any filter, then
the natural way would be to select nothing).

This also caused issues with category fields, when the action script
uses restrictedTraverse to get the uids corresponding to the category
but a path is empty, like for example in 
https://lab.nexedi.com/nexedi/erp5/blob/d51bb0413a806b3db0c5eb69dec06065b9601322/bt5/erp5_accounting/SkinTemplateItem/portal_skins/erp5_accounting/AccountModule_getTrialBalanceReportSectionList.py#L40-48

which does this:

```python
# optional GAP filter
node_uid = []
gap_uid_list = []
for gap in request.get('gap_list', ()):
  gap_uid_list.append(portal.portal_categories.gap.restrictedTraverse(gap).getUid())
if gap_uid_list:
  node_uid = [x.uid for x in portal.portal_catalog(
                                   portal_type='Account',
                                   default_gap_uid=gap_uid_list)] or -1
```

If an empty item is selected, then `gap_uid_list` will contain an entry for 
`portal.portal_categories.gap.restrictedTraverse('').getUid()` which will be the
uid of the gap base category. Searching with a base category uid nowadays does not
match any document, but before 95e3eaec (CMFCategory: Do not index any Base Category
as a related document., 2016-12-21), it was matching all documents having a relation
from this base category and in the case of this trial balance report it was matching all
accounts.

This was a problem for old instances with accounts created before 95e3eaec, because when
they were first indexed, they had the record in category table, so they were matched, but
once they get re-indexed, they no longer had the record, so the result of this report when
selecting the empty item became different, because accounts were no longer included.

Looking back at this, maybe when updating to get 95e3eaec, we should have ran a migration
to delete all these records (re-indexing every document in the background should be enough)
so that if there's a problem, the problem happens right now and not after a few months
after accounts are modified and re-indexed.

When looking at this from end user level, theses empty items not only cause this problem,
but also does not have a clear behaviour and are not needed, so the changes here are about
removing these empty items.

In accounting reports, there was a multi listfield showing all gap categories, "grouped" by
chart of account - but the name of the chart of account was not displayed. This change to
use a None item, which is rendered as disabled to display the chart of account name, but to
do this we had to fix a bug in Formulator, these disabled items were only working properly
for single item widgets, not multiple items widgets.

See merge request nexedi/erp5!1572

This addresses a regression from nexedi/erp5!1561 changing the class hierarchy caused Login to loose its docstring and became no longer publishable.

This was problematic because it was not detected by the test suite, so HTML test is changed to use zope publication instead of calling the view on the context.

Another notable point is that this behaves differently in ERP5JS, the Logins were still visible in ERP5JS. Because we don't actually rely on "no docstring on the class" to prevent publication, this is not changed.

See merge request nexedi/erp5!1571

There was opening and closing tags mismatch:
    <div><a href="#references1_anchor">References</div></a>

This seems to be used only in Localizer's ZMI. This is not compatible
with newer version of DocumentTemplate, but because we don't use, it's
better to remove the functionality

In order to stabilise UI tests which are waiting for the loading animation
to play during language change.
Pick a small delay so users should not notice (value suggested by Romain).

When we have more than one language and many documents with same reference but with different language, the first impression is that we have many duplicated documents.

Display the language, we can easily detect that we have same reference to different languages.

While in a "single" list field, we need an empty item that will be
selected by default, there's no such need on a multi list field.

These empty items also have the problem that their meaning is not
really clear.

Instead of having empty string items which for which the meaning is not
really clear.

processing_node -3 is not automatically used anymore, such failure would
nowadays be a processing_node of -2. So simplify this comment.

For example, an immediateReindexObject and a
SQLCatalog_deferFullTextIndexActivity may be spawned.

Without this, more categories than can be displayed in the dropdown menu
may match, pushing expected "Quantity" one out of the list, causing the
test to fail.

This is more realistic, because a real HTTP request will use
ZPublisher.BaseRequest.BaseRequest.traverse, which has slightly
different behaviour than getting the form on the context of document.

The behavior becomes different for documents which do some logic on
traversal (like for example the web sites changing the skin).

This was breaking for cases where values contained characters used for
markup such as <> or & and also for the special case of None which is
used to render disabled items.

Zope only publish objects if they have a docstring. The change in class
hierarchy from b7a60478 (ERP5Security,erp5: simplify
EncryptedPasswordMixin.setPassword, 2022-02-21) caused that Login and
subclasses no longer have a docstring and as a result there were no
longer publishable by Zope, so it was not possible to view them in xhtml
style. ERP5JS was not affected, because it does not directly rely on Zope
publication APIs.

We don't want to use wildcard in core business template, because when
another business template extend these paths with new documents, the
new documents are included in erp5_core.

This also cause issues for tests creating dummy content in these paths.

This was still working with Zope 2.13 because the default output_encoding for
HTML was iso-8859-15 but this is not the case anymore with Zope 4. Moreover this
should be explicit rather than implicit anyway...

Revert "testBusinessTemplateTwoFileExport: Make output_encoding explicit as it should have always been."

This reverts commit 968991e7 which does not
actually work properly with Zope4.

SQLCatalog_trimInventoryCacheOnCatalog needs resource category on movement.

This fixes a failure due to Zope4 now defaulting to utf-8.

Use `portal_alarms/check_consistency` after configuration to make sure that every document created by configurator or part of the dependency business template is valid.

For now we have two exceptions (that are some TODO for the future):
 - Web Sites, because upgrader constraints are not ran by configurator at this point
 - Business Configuration, because most of the configurator item classes don't fully follow the protocol of constraints, their `fixConsistency` method always return "something needs to be fixed" without actually checking.

See merge request !1562

Creation date is defined as the oldest date of any workflow history on the
considered document.
Modification date is defined as the newest date of any workflow history
on the considered document.
As soon as there is more than one workflow on a given document, these
values can differ: they are set with the wall-clock time at the moment
the workflow history of each workflow is initially filled, so one can land
just before a second change and the other right after.
So comparing them is meaningless, catalog or not, and just causes this test
to be unstable.

Because we want to check consistency on all documents created by
configurator, we also need documents created during the test to be
consistent (or deleted)

We had trade phase duplication:
 - `trade_phase/default/*` were provided by erp5_simulation_test
 - `trade_phase/trade/*` are provided by erp5_configurator_standard_categories

so the former was only for testing and the later were actually used in
instance configured by configurator.

But in some paths from configurator_standard_*template, which are also
used on configurated instances, were using trade_phase/default (the one
from test). Some rules were referencing these categories, but apparenlty
not using them.

To fix this confusion, use trade_phase/trade/* everywhere, and install
erp5_configurator_standard_categories where needed in tests.

BusinessConfiguration have a resource category, but it's the workflow,
it's not really a resource, so some APIs from the base Amount class are
not available. Because they have no meaning on BusinessConfiguration
anyway, define the broken APIs to return nothing.

This fixes errors trying to use check_consistency alarm on Business
Configurations.

Tools also contain documents, so it makes sense to check them as well