The logic of the patch accidentally changed in 240a8d26 (
{,Propertied}User: Reduce the overhead from Developer role processing.,
2019-02-14). This used to be a patch to not consider 'Developer' as
a local role in SimpleUser.getRolesInContext , but it was changed to
not consider 'Developer' role at all - also as a global role.

SimpleUser are users from the the root acl_users, users from
erp5/acl_users will typically be PropertiedUsers, because this is a PAS
user folder.

Call the original method instead of copy/pasting the code

We still keep the following patches:
 - user: this is an ERP5 addition and maybe we use it in customer project
   code (if we don't I'm in favor of removing the feature, it's used in
   only one place in this repo)
 - call `self.changeSkin(self.portal.getCurrentSkinName())`. Maybe this
   is needed for CMFCore tests and could be good to send upstream, I did
   not check this part

This reverts commit 8d81b128.

commit message was wrong

This reverts commit bf230f1f.

pushed by mistake

The logic of the patch accidentally changed in 240a8d26 (
{,Propertied}User: Reduce the overhead from Developer role processing.,
2019-02-14). This used to be a patch to not consider 'Developer' as
a local role in SimpleUser.getRolesInContext , but it was changed to
not consider 'Developer' role at all - also as a global role.

SimpleUser are users from the the root acl_users, users from
erp5/acl_users will typically be PropertiedUsers, because this is a PAS
user folder.

Globals.DevelopmentMode initial value is False but it is initialized to True at
Zope startup (App.config.{setConfiguration,DefaultConfiguration}).

In the changes from ExternalMethod 2.13.1 -> 4.5, now ExternalMethod
define __code__ (and __defaults__) to a computed attribute calling
getFunction, but getFunction is different in our patched class, so
when unwrapMethod tries to get __code__, it will raise and mapply
will not consider the external method as being callable, so a simple
__repr__ of the ExternalMethod will be used as response body when
published.

By defining __code__ to something using our patched logic, this
problem does not happen.

There's also a TODO because DevelopmentMode is now True, which uses
a different code path which was causing TypeError, because getPath
returns None, which os.stat does not accept.

We now must use Zope4 to export business templates to commit on ERP5
master branch

Duplicating the id is bad. Checking the meta_type is not perfect, but it
is one step better.

Updating pandas to 0.24.2 revealed as :

      File "develop-eggs/astroid-1.3.8+slapospatched001-py2.7.egg/astroid/raw_building.py", line 360, in _set_proxied
        return _CONST_PROXY[const.value.__class__]
    KeyError: <type 'numpy.ufunc'>

when linting code referencing pandas. The problem is actually with
some numpy `ufunc`, such as numpy.sin, but we don't seem to have code
using it in the test suite.

Creating Stripe Payment Session and HTTP Exchange in the same transaction can raise conflict errors and when it happens, we already created the session on the Stripe side.

With this, when this happens, we receive one useless webhook to inform that the session has expired.

Also, batch_mode was removed because we only use it in tests. The tests were updated to use like in production.

This change will probably avoid the issue below:

```
------
2023-03-01 13:03:33,503 INFO Tracking queuing message: activity=SQLDict, object_path=/erp5/stripe_payment_session_module/20230301-1B990F0, method_id=immediateReindexObject, args=(), kw={}, activity_kw={'group_id': '', 'serialization_tag': '/erp5/stripe_payment_session_module/20230301-1B990F0', 'alternate_method_id': 'alternateReindexObject', 'group_method_id': 'portal_catalog/catalogObjectList'}, user_name=...
------
2023-03-01 13:03:33,516 INFO Tracking queuing message: activity=SQLDict, object_path=/erp5/system_event_module/20230301-9DDE8DD8, method_id=immediateReindexObject, args=(), kw={}, activity_kw={'group_id': '', 'serialization_tag': '/erp5/system_event_module/20230301-9DDE8DD8', 'alternate_method_id': 'alternateReindexObject', 'group_method_id': 'portal_catalog/catalogObjectList'}, user_name=...
------
2023-03-01 13:03:33,549 INFO ZPublisher.Conflict ReadConflictError at ......_startStripePaymentSession: database read conflict error (oid 0x06be91ef, serial this txn started with 0x03eec0ca6bdaf611 2023-03-01 10:50:25.278590, serial currently committed 0x03eec0d78f096a55 2023-03-01 11:03:33.524245) (12 conflicts (0 unresolved) since startup at Tue Jan 17 03:21:57 2023)
------
2023-03-01 13:03:35,057 INFO Tracking queuing message: activity=SQLDict, object_path=/erp5/stripe_payment_session_module/20230301-1E233DB, method_id=immediateReindexObject, args=(), kw={}, activity_kw={'group_id': '', 'serialization_tag': '/erp5/stripe_payment_session_module/20230301-1E233DB', 'alternate_method_id': 'alternateReindexObject', 'group_method_id': 'portal_catalog/catalogObjectList'}, user_name=...
------
2023-03-01 13:03:35,066 INFO Tracking queuing message: activity=SQLDict, object_path=/erp5/system_event_module/20230301-5C3B7E3, method_id=immediateReindexObject, args=(), kw={}, activity_kw={'group_id': '', 'serialization_tag': '/erp5/system_event_module/20230301-5C3B7E3', 'alternate_method_id': 'alternateReindexObject', 'group_method_id': 'portal_catalog/catalogObjectList'}, user_name=...
```

See merge request !1747

erp5_core: remove Guard Role field in Worklist_view, as it should be defined in predicate listbox at the bottom.

Creating Stripe Payment Session and HTTP Exchange in the same transaction can raise conflict errors and when it happens, we already created the session on the Stripe side.

With this, when this happens, we receive one useless webhook to inform that the session has expired.

Also, batch_mode was removed because we only use it in tests. The tests were updated to use like in production.

See nexedi/slapos!1122 for SlapOS.

This listbox can be used to show documents that user is not allowed to
access, so this `cell/getId` can raise. In Zope2 it was raising
Unauthorized and this Unauthorized was catched, on Zope4 it is raising
NotFound, which is no longer catch since 850e436e (
Products.ERP5Form.Form: Let NotFound exceptions propagate during
rendering, 2022-11-25), so this NotFound was raised as a site error,
which caused an error in the test.

Only the most used forms are updated

This middleware is enabled in Zope's mkwsginstance [1] and also in test,
[2], we should also enable it here for consistency.

It is necessary to handle exceptions when no standard_error_message
skin exists, like it is the case today in RJS skin selection.

1: https://github.com/zopefoundation/Zope/blob/828b1973e39f4dc1bf51fea0cd11a236d28ec3b5/src/Zope2/utilities/skel/etc/zope.ini.in#L16
2: https://github.com/zopefoundation/Zope/blob/828b1973e39f4dc1bf51fea0cd11a236d28ec3b5/src/Testing/ZopeTestCase/functional.py#L136

It's not functionally different and this way it is more beautiful on
Zope 4

Update ZMI pages with the design of Products.ZMySQLDA and with the
usage of manage_page_header, which sets the content-type to html

Products.CMFCore.CachingPolicyManager.CPMCache became a new style class

because __str__() returns id in Zope2 but returns login in Zope4.

XMLExportImport encode strings in base64 when they can not safely be
represented in XML (including for exemple "\n"), so we can not use
this information to decide if this a BINBYTES or a BINSTRING pickle
opcode.

For now, it's still unclear how bytes and str should be handled, so
while using python2 it's better to keep using str everywhere and not
introduce zodbpickle.binary that looks like str on python2 but will
become bytes on python3 and have consistent data everywhere (ie.
everything str)

BINBYTES is not fully removed from the patch, because we'll want to
use it later, but it is in "if" that is always false.