This was creating different message for each number of tasks

This uses an internal API that has changed in 0aeea3c4 (Validation
message translation, 2021-01-06)

With this, user can see stop_date from events

With TALES in default, we prevent acquisition from the start date. When default is None, the field will try to display now on the stop date.

The goal is, if stop_date is None, we don't display anything in this field.

stop date is very useful to Phone Call and Visit. For example, if you want to calculate the time spent in one phone call, you can handle it using start and stop date.

But, Event_view does not display stop_date. So, we display stop_date if hasDuration is True.

No need to introduce one more random number here,
anyway the tag that is passed to this script contains one, so use that

Base_report needs to get also the cleanup_tag
to make sure it is launched before active process is deleted

When rendering a proxy field, 3 different fields can come in play:
1. the field to be rendered
3. the template field (i.e. not a proxy field) that knows how to render
2. possibly an intermediate proxy field that contains the value to render

What's difficult when rendering a proxy field is to take the above 3 fields
into account and this commit does it by creating a temporary field:
1. 'field' variable in TALES
2. the value
3. the code

Before this commit, 1 could be wrong.

This was deprectated because we don't have get*ById for other modules
and tools, we just use OFS API. This should also be slightly faster
because one less method call (and one less call to warning)

exiting the context manager restores the original DateTime behavior

This tests the test framework, because this code is tricky.

I'm not sure if this is used, but not being valid python code cause
problems with code analysis tools

Maybe this made sense long time ago, but nowadays we are using
equivalence testers which tolerate date differences with more flexibility.

createDateTimeFromMillis was also problematic as it uses internal
private attributes of DateTime which is a pylint error with more recent
DateTime

Permissions are managed by the document_publication_worflow

Most service worker precache scripts reference a favicon.ico, but this
is using the default favicon.ico from Zope and even though it was included
in all ERP5JS and OfficeJS web sites, this was mostly not used, only
web_renderjs_ui web pages reference favicon.ico.

There's a favicon.ico in erp5_xhtml_style skin folder, but the skin
folder is not in ERP5JS skin selection.

On Zope2, this caused ERP5JS and OfficeJS application use the default
Zope favicon. On Zope4, the service worker can not fill its cache
because of 404 errors, because since Zope commit 4f0770941 (Retired
icons from the `Zope Management Interface` and various smaller cleanups
of ZMI screens., 2011-07-02) there's no default favicon.ico anymore.

To solve this, provide a favicon.ico in ERP5JS skin selection, by
copying the one from erp5_xhtml_style. We also reference it explicitly in
web site layout properties so that it remain in the cache.

OfficeJS applications do not use favicon.ico explicitly. They use icons
in their web application manifest, but this does not seem to be use as
favicon unless the PWA is installed. This part is not addressed by this
commit.

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