while setting an initial user id should be allowed for any user which can
create a person, changing an already set user id can have security
implications, so we protect it with a more strict permission

This activity is spawned on all nodes, which cause too many conflicts.
We can take the risk here, assuming that references were already OK
before migration.

Person.setUserId does expensive checks to ensure that user ids are
uniques, but the default id generator already guarantees unicity, so
when default id generator is used we don't need Person.setUserId unicity
checks.

Now when generating user ids, we only consider user id conflict with existing
users, because it's not so expensive and might still happen, for example if
user ids have been migrated from person references when erp5_users PAS plugin
was used.
person.setUserId still performs the expensive checks to prevent duplications
against other transactions using person.setUserId, but not against other
transactions using person.initUserId

should be same for cases where type based method is a python script, but
is a bit more explicit/safe and consistent with other usages.

In 93e30e5e (Person: Store user id in new user_id property., 2016-12-09)
we adapted this test to the new behavior: title fallback to user_id or
id, but since persons always have a user_id by default, this test was
changed to check that title fallbacks to user_id, but the name of the
test still mention "fallback to id" which became a bit different from
what was tested here.

Revert testEmptyTitleFallbackOnId to check that title fallbacks on id,
using persons without user id and introduce new
testEmptyTitleFallbackOnUserId to describe the new behaviour with user
id.

See merge request nexedi/erp5!1244

See merge request nexedi/erp5!1241

See merge request nexedi/erp5!1239

1. title is not exact match
2. can't search title in objectValues

Configuration generated by Standard Configurator was not really good. For most divergences, there was no solvers configured, so users could not configure divergences. Now solvers (for packing lists) are configured so that every divergence is automatically accepted, we only expect user to take a decision when quantity or resource is different.
This change was implemented in the rules from `erp5_configurator_trade_template`, but because several simulation tests were relying on the fact that "changing anything would cause a divergence" the previous rules configuration are kept in a new `simulation_test_trade_template`.

Also, security configuration was incomplete, since the introduction of "new simulation", some Unauthorized errors occurred when non-manager users where trying to solve divergence. This is now solved and exercised in the integration tests we run on auto-configurated instance. 

The configuration was obsolete, nowadays we use different business processes for each use case, this configuration was still using only one business process for both sale and purchase, now we use two and improve the accounting configuration, to use accounts defined in supply line.

Some others small improvements were made, for example now we can configure the delivery solver to use for a split solver once and for all in the solver and user does not have to choose each time.

What not updated this time:
 - divergences on Invoice Lines: this is probably same as on Packing List before these changes
 - rules are still configured with ad-hoc scripts and not based on trade phase categories.

See merge request nexedi/erp5!1221

See merge request nexedi/erp5!1236

Since 248f59e5 (Business Template: Likewise ERP5Site.addERP5Tool(), do
not re-create Tool if it already exists., 2020-06-22) we no longer
update tools, because of the problem that business template does not
currently handle updating objects with lots of sub-objects.

But we realized that we really need to update tools when they contain
configuration as object attributes, like mimetypes_registry, where the
problem was observed.

Instead of unconditionnally skipping any tool during update, we only
skip the ones that were initially managed by ERP5Generator and are moved
to business templates.

to match the button on the front page

With virtualhosting, there can be an empty path element at the beginning
of the path.

Try to find a full message translation before falling back to
generic translation using ${portal_type}

Most of jump methods were already doing this correctly, these were some
exceptions.

The "New ${portal_type} created." is impossible to translate in
languages using genders for nouns, for example in french, New is
translated as "Nouveau" for masculine portal types and "Nouvelle" for
feminine portal types.

Instead, translate the full "New Support Request created." sentence.

See merge request nexedi/erp5!1233

organisation logo is not accessible for anonymous

upload document and run all activities around this upload takes time, so we use a larger timeout

erp5_officejs_support_request_ui_test: Add test to make sure we have all expected actions to access support request web site

* Check if each portal_type has the expected view action
* add test to cover all possible attachments in a Support Request

erp5_officejs_support_request_ui: Simplify code to render the expected action to preview any attachement document

Hard coding to select action_object_view we will never use web site configuration.

If we always get links from action_object_view, Support Request will always break if we change View Action Category on web site.

Having a big "Generate RSS" button on the front page is strange, because the front page button are for common use cases that users are supposed to execute a lot.

For example, makes sense to have a "Submit new Support Request" button, because users are using this app to submit support requests, but generating RSS is very exceptional action, so we wanted to remove it from the front page.

Also, we changed:
- change the generate_rss_link action in Support Request Module, to directly call SupportRequestModule_generateRSSLinkUrl.py instead of the form.
- change SupportRequestModule_generateRSSLinkUrl to display the form at the end.
- Use Base_renderForm like for erp5_crm
- Put the RSS url in the REQUEST
- change the gadget field configuration to use the value from the REQUEST (if not found, put None)
- change the gadget implementation to display the URL in an html5 string field  + a button

See merge request nexedi/erp5!1227

Without it, it is not possible to upgrade instances since:
nexedi/erp5@48c45fbd

[test/upgradeOldDataFS] use UI callables
Ensure the admin will able to trigger the upgrader

erp5_corporate_identity_test: test pdfs are only used to store data then check converted image, so one pdf is enough

- test updated