erp5_search_rank_catalog: do not destroy the previously calculated rank

erp5_search_rank_catalog: Show module content before tools content

erp5_search_rank_catalog: keep default value low, to prevent having huge rank score

With the new workflow implementation, error_message variable is required, because
we intentionally clone previous workflow history entries when passing transition,
as this leads to smaller pickle size

See merge request nexedi/erp5!1560

Use the html_viewer gadget

fix internal API mis-use and other small fixes

See merge request nexedi/erp5!1583

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.

For now only checks that error_message is missing, but later we might
extended this to perform more check on the workflow definition.

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.