To "mark as read" and open preview, the front page gadget uses the "md5" key,
which is calculated from "link", but we can have multiple entries for the same
links, like it's the case for officejs_support_request app.

Instead, use guid or id if available, this is what RSS/atom use for this purpose.

Instead of expecting exactly actions with "preview" or "view" name, take any
action which name contains "preview" (or title is "Preview") or name is "view".

This makes it easier to include support request applications in different
applications, where the default actions might have a different name. This also
fixes the preview link for File portal type, because there was no "preview" or
"view" actions for File.

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

Graph layout is part of the workflow, a bit like the description.

These are rendered with a loop from the state to the state, it's ugly and not
much informative, remove them for now. We could use different edge styles for
"worklow method only" and "workflow method and user action" transitions and
render this as only one transition. We could also change the data model of
workflow itself, now that this is no longer using DCWorkflow.

This is required with ERP5JS, where every save call render with new data.

When no schema for the edge, don't try to show edge edition dialog. Until now
this was crashing

 - make the gadget full page, this is better when using in an iframe
 - "highlight" the currently hover edge, which makes the graph more readable
 when there are overlapping edges.
 - user helvetica font every where

This introduces a new gadget_graph_editor.html gadget, for use in iframe and
keep the existing dream_graph_editor/jsplumb/index.html for use in "public"
scope, ie. without iframe.

as explained in comment, this API is asynchronous but the promise to await is
not exposed

At the beginning of tests, there is Tests completed in {a few milliseconds}, so
this was reporting success before the test even run.

 - We don't care about a stable random layout, we want to include the
manual layout in business templates
 - Re-add edge edition dialog that was removed
 - Drop a wrong CSS that was removed long time ago but re-added by mistake
 - Don't do CSS in the javascript, the graph model allows to have CSS in
the model