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 nexedi/erp5!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.