This addresses a regression from !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 !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.

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

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

These documents were probably edited before they had correct property
sheets, because they had local properties as incorrect type, as reported
by PropertyTypeValidity:

    <ERP5Type.ConsistencyMessage for PropertyTypeValidity type_check on portal_gadgets/erp5_persons (message: Attribute gadget_type should be of type lines but is of type <type 'str'>)>
    <ERP5Type.ConsistencyMessage for PropertyTypeValidity type_check on portal_gadgets/erp5_gadget_new_sale_opportunity (message: Attribute gadget_type should be of type lines but is of type <type 'str'>)>
    <ERP5Type.ConsistencyMessage for PropertyTypeValidity type_check on portal_gadgets/erp5_gadget_contact_person (message: Attribute gadget_type should be of type lines but is of type <type 'str'>)>

For historical reasons, EncryptedPasswordMixin.setPassword was public
and did its own security checks, this was the case since 7d0882ef (
setPassword have to do explicit security checks…, 2007-11-12), this was
because we wanted to support cases where user can edit the login ("Edit
portal content" permission), but not changed the password ("Set own
password" permission).

Also, we wanted to support the case where login is edited through a view
form, in that case we have a my_password field that is empty and we
don't want to set the password to None in that case.

For these two reasons the API to set password was very complex and
behaving differently from other accessors: usually setSomething(None)
just set something to None, ie. "unset" something, but for passwords it
was not the case. Also we had to introduce _forceSetPassword method,
which sets the password without security checks, so that it can be
called from unrestricted code for cases where user does not have the
permission to reset password (like in the reset password scenario).

Since d1312cdb ( make edit check the security remove all useless
security declaration on private method, 2008-05-23), edit supports
restricted properties, so we can simplify all this and make setPassword
a more standard accessor, ie:
 - setPassword has a security declaration, so if it is called from
  restricted python the security will apply at `__getattr__` time.
  `edit` method will also check security
 - setPassword(None) reset the password.
 - The logic to not change the password when editing in view mode is now
  `edit` responsability. ie. `login.setPassword(None)` resets, but
  `login.edit(password=None)` does not reset.

This also correct some usage of the lower level API (`pw_encrypt` and
`pw_validate`) which were never supposed to use `None`:
 - `pw_validate` was called with None when a user without password was
  trying to login, causing a TypeError that was cached by PAS and logged
  with level debug (and refusing login). Now the error is no longer raised.
 - `pw_encrypt` was called with None (but apparently only in the tests,
  when doing `user.newContent(portal_type='ERP5 Login', password=None)`)
  and this was creating a login with password `'None'` with AccessControl 2.
  With AccessControl 4 this was an Error.

reorder methods, make some docstrings a bit more informative and fix
several typos

This disable price lookup on domains, because it errors and because the
meaning is not clear.

It errors because Domains are MetaResources, so they are subclass of
Resource and they inherit the price lookup mechanism, which does not
work on domains because of their different `getRelativeUrl` implementation.

check_consistency alarm checks that every document created satisfy
contraints. This is done in order to verify that configurator it self
create consistent documents and also that all default documents from a
realistic configuration are consistent.

the API is not to return a list of strings, but a list of ConsistencyMessage

Replace it with a method on ERP5Type.Base so these activities get found
by CopySupport.unindexObject and flushed, rather than remaining on the
interaction workflow's context and failing when run.
It seems a lot more likely for a document to be deleted while interactions
are being spawned than an interaction workflow itself. So this should be
a net benefit in activity stability.

This currently only works because CookieCrumbler reacts on *all* urls which
contain the magic login & password fields. But the POST request body lacks
any value from submit fields, which bypasses the "logged-in" scripts, which
is harmless with current code but lack realism.

See merge request nexedi/erp5!1516

The initial idea was that publishing documents is something really exceptional, the "attach document" normal use case is typically use cases like attaching a PDF invoice to an invoice document in accounting, ie. most of the time it's with sensitive information that we don't want users to be mistakenly publish on the internet just because they selected a wrong value in the field.

Now we have a project with use cases where the attached documents needs to be published, we did not change our mind that publishing an attached document is an exceptional case, but we want to make it possible to configure so that in certain contexts, publishing documents is possible.

So we reuse the existing configuration by type based method idea and when the getPreferredAttachedDocumentPublicationState returns "published" we make it possible to publish by default.