it supports text, but unless they have non-ASCI characters, so it's
better to always pass bytes.

In original Products.ZSQLMethods, this is text, we want to keep the
same semantics and encode only at a lower level.

MySQLdb's string_literal is a method from the C API and the name is not
natural for python programmers, because it manipulates bytes. It
supports str, unless they have non ASCII characters, so it's better to
always pass bytes.

On python2, this change repairs a regression visible when searching
catalog with translated related keys. This regression was introduced in
the merge of zope4 support, more specifically with 610972af (py3:
Update Shared.DC.ZRDB.{sqltest,sqlvar} monkey patches., 2022-04-16),
because with the new version of the patches this method gets passed
unicode strings, which is fine, unless they contain non ASCII characters.

This reverts commit 149fdd1d.

This did not support the case of updating old emails for which
url_string was set, it was setting coordinate_text and causing
emails to have two properties ( url_string to the old value
and coordinate_text to the new value ).

See discussion on nexedi/erp5@149fdd1d (comment 180744)

- make the editor bigger
- use monospace font for params

This can happen with cross origin document, when using open on another
domain. In that case selenium crashes and the test never finishes, this
allows selenium to finish and report the error.

With 12f110d4 (testTableStructureMigration: update test after
mariadb 10.3.38, 2023-02-22) we changed the test to support mariadb >=
10.3.38 but it broke the test under 10.3.35.

This makes the test support both 10.3.35 and 10.3.38.

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.

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.

On Zope4 these settings are no longer in zope.conf