Do not access form submission REQUEST from the listbox list method,
as it is rendered asynchronously in ERP5JS

This reverts commit 35b2c024.

Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

erp5_web_renderjs_ui: keep previous focus color

This reverts commit a87db49b.

Drop user informations from language page

We received a few support requests from users who are able to change their
password but not to log in afterwards. These users probably copy and pasted
their user name with an extra leading or trailing space. In the reset
password dialog, these spaces are stripped, because Formulator by default
strips the input (unless "whitespace preserve" is on, but we usually don't
set it except in text areas).

Historically we have been completely avoiding the extra spaces and made the
login/user_id case sensitive, because login and user id were the same thing
and there have been issues when looking up user id in mariadb because of
mariadb collations, so we took the easy way of saying "logins are case
sensitives and spaces also mater", but with separate login / user id,
this can be revisited, because the login is only used to check the password
and find an user ID.

Stripping spaces from logins is a common thing these days (google, twitter,
facebook strip logins) which simplifies user experience and reduces support.

The risk of conflicts seems very low, if users are created with ERP5 Forms
Formulator already had stripped the login anyway. After this change in case
of two user names ('alice' and ' alice ') conflict, none of them would be
able to login.
We keep compatibility with users with trailing spaces, so if there is only
a user named ' alice ', without other users that would conflict (for
example 'alice' or ' alice'), this user remain able to login anyway. This
last part is probably not so important in reality, it is for compatibility
with testPasswordTool.TestPasswordTool.test_login_with_trailing_space

* Fixes https://erp5js.nexedi.net/#/bug_module/20160609-11B02E6 and https://erp5js.nexedi.net/#/bug_module/20210517-F12266
* Support ERP5JS
* Improve test coverage
* Small CSS changes
* Fix bug editing business process when erp5_graph_editor was installed 

See merge request nexedi/erp5!1461

Until now, portal_sessions was only reliably usable when using a family with only one zope node, because the session data was using RAM cache.
When used by authenticated users it was more or less usable, because of haproxy
sticky cookie that we set for authenticated users, but for non authenticated users
this was basically unusable.
This was especially a problem for CaptchaField, for which users are generally not
authenticated.

This changes portal_sessions to use a distributed cache, which brings several
differences:
 - sessions are now shared between all zopes of a cluster.
 - storing ERP5 temp documents is still possible, but modifying a temp document in
   session does not automatically save the changes in session, for next session read
   to be using the modified document it's required to save the document explicitly.
 - session respects transaction semantics, changes are only persisted in session when transaction commits successfully.
 - `portal_caches.clearAllCaches` API no longer clear all sessions.

See merge request nexedi/erp5!1451

See merge request nexedi/erp5!1466

See merge request nexedi/erp5!1464

There was a wrong assertion in an interaction workflow, preventing saving from
other tabs than the graph editor

- set validator, this is now required to be able to edit
- use an iframe for ERP5JS compatibility
- clean up this form, it had some unused disabled fields, remove them
completly instead

and also enable coding style on this bt

- set validator, this is now required to be able to edit
- use an iframe for ERP5JS compatibility

- set validator, this is now required to be able to edit
- use an iframe for ERP5JS compatibility