When using checkPythonSourceCode integrated in the source code editor,
for a scenario where developer edit a component and save we can benefit
from caching the check message for the source code content, because the
same check that the one happening in the editor will happen when the
component is saved.

This cache varies on:
 - "component_packages" cache cookie which is reset every time some
component code is edited.
 - zope startup time to take into account editions of file system code.
This assumes that after reseting file system code zope will be
restarted.
 - portal_type, because the checks performed by this function also
depend on portal type.

this makes completions works when using Ctrl+space

This makes "Format Document" / "Format Selection" work.

because pylint is a bit slow on large components, debounce every 2
seconds. TODO: this is too slow.

For now this is just the portal_url, but I'm thinking it could be a
proper tool.

IIRC the only thing needed is that ERP5TypeTestCase.getPortal is an
ERP5Site

on very large python files (>1000 lines) sometimes they queue up and we
have to wait for all requests that were queued by zope.

XXX maybe this does not happen when accessing through haproxy/apache, I
am observing this when hitting zope directly

because title is acquire from id, we want to edit title first for the
case where we change ID, otherwise saving would save the old ID as
title.

 * don't set "hide rows on no search criterion", this should not display
too much and search is broken.
 * use preference to get number of lines

This can hide bugs, especially when updating business templates.

TODO: if we drop this we can also drop the command line flag

Until now, a reset was performed even though ZODB Components were not created or
replaced. Introduce a new installation hook to avoid those useless resets.

When installing bootstrap bt5s, erp5_base, erp5_simulation: 33 => 12 resets.

Improve consistency with document view

The changes from nexedi/erp5!1158 were not so good in ERP5JS, it was good to have the action here:

![stock browser dialog showing Stock as a view action](/uploads/0e9495858295016926da484b6c5fa68f/image.png)

and not under "Exports", because this is not an export, it's an interactive report.

Also, the "Stock" button is not easy to understand, this is not an action, so we use only an update button now:


![stock browser dialog with only an update action, no action](/uploads/71f40b3e2e951f3c95f7ff885dd91090/image.png)

Also, the action button in movement history was confusing, it's not a button where user have to click. It was like this, with a confusing button (but this button was sometimes useful, because with this button we can go back to stock browser):

![movement history before](/uploads/75450d7fbfe1f208ca17e14b22059b38/image.png)

Now it's like this, the button is not here, but since the action is now listed in Views, it's easy to go back to stock browser:

![movement history after](/uploads/d66d28f1fc66b69b84baba6d88574afc/image.png)

See merge request nexedi/erp5!1179

Since 5eb06085 (erp5_web_renderjs_ui: do not display submit and cancel if action is empty in form_dialog., 2020-06-10) ERP5JS does not display submit button, this continues in this direction to:

 - Apply the same possibility in xhtml_style to not show a submit button when there's no action. In xhtml_style we show the cancel button using the same rules as everywhere else.
 - Fix error in ERP5JS for dialogs with only an update action but no action.

See merge request nexedi/erp5!1181

Change login button to comply with Google's branding guidelines.

Add support for google login in ERP5JS.


See merge request nexedi/erp5!1166

See merge request nexedi/erp5!1171

There's nothing wrong in having more than one listbox in a dialog

The initial intention was to "disallow invalidated", without forcing users to
validate everything, but it was probably a mistake, if users don't need to
validate then validation workflow would be a bit meaningless.

This is made after an incident where a user mistakenly cloned a validated
currency and the cloned currency was available everywhere in the system.

Change to not return draft currencies by default and also change so that all
items are tuple, for consistency. That should have no impact and is a bit
easier for the test.

Also adjust accounting_ui_test, we need to validate currencies for the tests
and clear cache if we validated some (but we don't need to clear cache if we
validate accounts, because account caches is more clever and does not need to
clear all cache)

also, we don't send passwords by email

Since the workflow is linear, make sure the states and transitions are
sorted in the listboxs in same order as workflow, this makes
re-configuring the workflow a bit easier.

The views for States and Transitions have an `int_index` field, but the
property sheet was missing.

The term is "Region", not "Country"

Unused aq_base imported from Acquisition (unused-import)

See merge request !1176

WebDAVSupport module was migrated to ZODB Components in 21becf4c. This module
contains a monkey patch (5c7d50d5) on webdav.NullResource.PUT which should
really be in Products.ERP5Type.patches and was not applied anymore since the
migration.

This is not a dialog where user can do an action, it's just a dialog where user
can change the parameters and update the to see the stock levels, so this
should be using only an update action (now that this is supported).

This is the view when using drill down on stock browser, there's no action
here, this is not a dialog where user can "Do something" so a button to "Do something" is meaningless.

One reason for this button was to be able to go back to stock browser, but:
 - in ERP5JS, user can go back to stock browser by clicking again on "Stock"
   action from Views actions.
 - In erp5_xhtml_style, user can click the list header or breadcrumb.

In ERP5JS we want the "interactive reports" to be available like other view
actions, directly in the left side panel. Also "Report" are named "Export" in
this interface (which might actually be a mistake, but it's like this now).
Rendering a form_dialog in a view action works perfectly in ERP5JS, so we can
take advantage of this.

In xhtml_style, this can not be a object_view action, because object_view
actions can not use form_dialog, this breaks the navigation.

So split in two actions, to have the best of both worlds

In that case the action button is not displayed.
If there's an update action defined on the form settings, update button is
displayed.
Cancel button is displayed using the same rule as any dialogs (ie. everytime
there's a cancel_url in request)