These are simple report/exports, they work fine with ERP5JS

Since a long time python unittest provides good assertions and we don't need to
build out own.

If a Credential Request/Recovery can not be accepted, the alarm should not
retry again and again.

We use an hasActivity test before trying to accept to prevent causing multiple
failing activities, if it already failed once, no need to retry more,
CMFActivity built-in retry mechanism is enough.

- Use ³ instead of the HTML entity form, ERP5JS does not allow HTML in field names
- Make Component_view uses Base_viewPDMFieldLibrary, like Product_view
- Add the proper description of this in field library
- Resource_viewFieldLibrary/my_base_volume is kept, for compatibility (not sure it's needed)
- Adjust ERP5Site_checkNamingConventions to allow m³, not m&179;
- Update all translations

We sometimes used "Invalid search criteria", sometimes "Invalid Search
Criteria". Unify to use "Invalid Search Criteria" everywhere

See merge request !1177

See merge request !1182

    The separation aims to reduce the dependency required to use the macros, where:

       * erp5_web_renderjs_ui_test contains the tests and the dependencies to run the tests
       * erp5_web_renderjs_ui_test_core contains the reusable macros, that can be used on other projects to write their own tests.

This is a first prototype showing how a site rendering can be modified
on the style with a renderJS gadget (to remove, add, modify current page
elements).

The navigation is automatically handle by the javascript (with the
pushState API), which really speed up the navigation on powerless
machine (like Pinebook Pro).

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

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

Add support for google login in ERP5JS.


See merge request !1166

See merge request !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)

update should still be usable in this case

testUpgradeInstanceWithOldDataFs: Upgrade erp5_upgrader too (it was in keep
list until now) as old Data.fs contains ERP5UpgraderUtils Extension with import of
Products.ERP5Type.Log. Although, erp5_upgrader should probably be automatically
upgraded before even starting the upgrade...