`zope_quick_start` was a dtml that was removed in Zope commit c8e4cd5ca
(Simplify control panel objects and actually make them non-persistent.,
2016-08-14), but it is referenced in /index_html page template, which
contains:

    <tal:text tal:replace="structure context/zope_quick_start" />

As a result, rendering / is an error page because of KeyError: 'zope_quick_start'

In SlapOS setup, we are using / in an haproxy health check, so the
health check fail and zope is marked as down and haproxy does not send
requests to backend.

We could have an upgrader constraint to repair this page template, but
because of this, zope is unreachable through haproxy, so it's easier to
ressort to monkey patching.

Zope4 inituser is decoded by decode('utf-8') on Zope startup and it is unicode on python2,
therefore it raises UnicodeDecodeError when searching non ascii charater on catalog.

  Traceback (most recent call last):
  File "<portal_components/test.erp5.testERP5Catalog>", line 4144, in testSearchNonAsciiWithTheInitUser
    person_module.searchFolder(title=person_title)]
  File "./erp5/product/ERP5Type/Core/Folder.py", line 452, in searchFolder
    return self.portal_catalog.searchResults(**kw)
  File "./erp5/product/ERP5Catalog/CatalogTool.py", line 819, in searchResults
    return ZCatalog.searchResults(self, sql_catalog_id=catalog_id, **kw)
  File "./erp5/product/ZSQLCatalog/ZSQLCatalog.py", line 1070, in searchResults
    return catalog.searchResults(REQUEST, **kw)
  File "./erp5/product/ZSQLCatalog/SQLCatalog.py", line 2362, in searchResults
    **kw
  File "./erp5/product/ZSQLCatalog/SQLCatalog.py", line 2326, in queryResults
    **kw
  File "./erp5/product/ZSQLCatalog/SQLCatalog.py", line 2214, in buildSQLQuery
    only_group_columns,
  File "./erp5/product/ZSQLCatalog/SQLExpression.py", line 397, in asSQLExpressionDict
    'where_expression': self.getWhereExpression(),
  File "./erp5/product/ZSQLCatalog/SQLExpression.py", line 298, in getWhereExpression
    result = self.sql_expression_list[0].getWhereExpression()
  File "./erp5/product/ZSQLCatalog/SQLExpression.py", line 303, in getWhereExpression
    result = '(%s)' % (operator.join(x.getWhereExpression() for x in self.sql_expression_list), )
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 25: ordinal not in range(128)

This is necessary on Zope4 because the error page is executed even if
the response already has a locked body - and in this case we don't
want to override the content-type header that might also have been set.

One user of this is Base_redirect from erp5_hal_json_style, when
abort_transaction is True, in that case it sets a body in json, a
content type header of application/json and then raise a redirect so
that the transaction is not commited. This fixes a problem visible on
Zope4 with erp5_bank_reconciliation_renderjs_ui_test:testFunctionalRJSBankReconciliationAction

Even if this is not used because we have locked a status earlier, the
constructor expects an URL with zExceptions 4

zopefoundation/Products.CMFCore commit 882a697 (- correct check for
request compatibility for CookieCrumbler, 2017-05-12)

Zope4 uses urlparse + urlunparse to encode the URL, which has a side
effect of removing the empty fragment from the URL. Using a lower level
API to set the status code and the Location header we achieve the same
result.

On Zope2, there was support for starting a ZServer (in
Testing.ZopeTestCase.utils.startZServer) and there was another makerequest
(in Testing.ZopeTestCase.utils.makerequest) which had knowledge of this
ZServer address. We are using our own implementation of startZServer,
which also knows how to start a WSGI server, but we we were interacting
with Testing.ZopeTestCase.utils so that its makerequest knows about
our web server.

On Zope4 there is no utility to start an http server from the tests and
the makerequest is also gone.

This revisits the web server from test interaction with makerequest:
 - no longer use PortalTestCase._app which creates an app with a request
   to http://nohost, but implement our own _app which creates a request
   to our web server
  - store our server address as class attributes on ProcessingNodeTestCase
   instead of patching pseudo constants in utils (these pseudo constants
   no longer exist)
  - in the case of ERP5TypeLiveTestCase, also rewrap the site to use a
  request to our web server (which was done on Zope2 by using
  Testing.ZopeTestCase.utils.makerequest and not
  Testing.makerequest.makerequest directly)

Update to https://github.com/plone/Products.PortalTransforms/blob/3.2.0/Products/PortalTransforms/transforms/rest.py
because Zope4 no longer ship with a reStructuredText module and recommend
using docutils directly instead, which is what upstream did.

( in zope4py2 branch this was working because slapos patch
component/egg-patch/Zope/0001-OFS-XMLExportImport.patch used to bring
back reStructuredText but we don't seem to need it )

Zope2 did not have WSGIPublisher, this patch was a backport of the
module from Zope 4. Now that we use Zope 4, we no longer need to copy
the module code, but we still need a patch to apply the deadline patch.

There are some few differences:

In Zope4 exceptions are callable, but we don't want to call them here,
so we use a python: expression instead of the path expression which
tries to call error_value.

error_message is sometimes not passed.

The context is different: Since Zope 4, the `standard_error_message` is
rendered in the context of REQUEST['PUBLISHED'], which in case of
publishing a skin (page template or script) in the context of a document
is is the skin itself, but for error rendering in case of erp5_web Web
Site or Web Section, we expect standard_error_message_template to always
be rendered in the context of the document, that's why we use
REQUEST.PARENTS[0] as context.

  REQUEST.PUBLISHED = <PythonScript at /erp5/script used for /erp5/module/document>
  REQUEST.PARENTS [<Document>, <Module>, <ERP5Site>, ...]

In case of redirect, the body is no longer empty, but we explicitly
return an empty body to keep the same behavior as zope2

This reverts commit eaae74a0.

On Zope4 branch we are ready to use __code__

This supports both python2 and python3. For python3, this decode() properly
arguments returned by string_literal() to have str(), otherwise the query string
is an str() (DocumentTemplate) and the arguments are bytes().

In other places, bytes() is used directly but in this case this is not needed
and would require monkey patching (at least) DocumentTemplate.

This changes slightly getOutput, `Status` is not printed as an header
(Status: 200 OK) but only in the status line (HTTP/1.1 200 OK)

In case of ConflictError, request will be retied for
HTTPRequest.retry_max_count times. For Zope 2, the default value of the
class attribute was 3, but on Zope 4, default value is 0 and this is set
to 3 on startup (by Zope2.Startup.handlers.root_wsgi_handler).
This startup code is not executed by runUnitTest, we need to set
HTTPRequest.retry_max_count somewhere, otherwise ConflictError are not
retried during tests.

The status message no longer use system-msg class, use simpler
"assertTextPresent" that should be enough.

Simplify the waiting for static pages, clickAndWait is enough.

With zope.tal 3.6.0 - commit 26fadc4 (Increase the default value of
the `wrap` argument from 60 to 1023 characters, to avoid extra
whitespace and line breaks., 2011-08-20) from zopefoundation/zope.tal -
page templates keep the attributes on the same line and produce
slightly different output, although equivalent.

This commit updates the places where we do snapshot testing to the
new output. We discussed using lxml features to compare html and xml
from https://lxml.de/lxmlhtml.html#running-html-doctests but because
the corporate identity web pages are invalid html, it seems unsafe
to rely on lxml at this point. Once corporate identity web pages
are fixed this would probably be a good thing to do.

zope.conf of Zope2 (zopeschema.xml) used to define event/Z2 log files and
properly configure logging but this is not the case anymore with
Zope4 (wsgischema.xml).

This adds path to event/Z2 log files as command line parameter as we probably
don't need further configuration such as message format (SlapOS recipe has never
handled it anyway).

Also, `__code__` has been introduced in Python 2.6 (for forwards compatibility
with Python 3) as an alias to func_code which has been completely removed in
Python 3.

This fixes testFunctionalCore failures:
  [...]
    Module ZPublisher.mapply, line 53, in mapply
      code = f.__code__
  AttributeError: 'DefaultGetter' object has no attribute '__code__'

See Revert "zope patches: display OFSFile content using full available height in zmi".

This fixes testBigFile failures because of `size` not being set to 0 when `data`
is set to None.

Modify DTML templates likewise Zope4 removal commit:
  commit 1df76c1ea8911d7d9249eb6beab1fafd4ed5803c
  Author: Hanno Schlichting <hanno@hannosch.eu>
  Date:   Sun Jul 3 14:19:26 2011 +0000
      Removed `bobobase_modification_time` from `Persistence.Persistent`, you can use `DateTime(object._p_mtime)` instead.

This fixes failure on test_PROPFIND_on_document (testWebDavSupport).

This reverts commit 8f5497d4.

This is not longer needed - with Zope 4 the ZMI is better and we now
have possibility to edit most of these through ERP5 user interface.
The main motivation is that these kind of patches are really hard to
keep up to date.

This reverts commit 88786a70.

This is not longer needed - with Zope 4 the ZMI is better and we now
have possibility to edit most of these through ERP5 user interface.
The main motivation is that these kind of patches are really hard to
keep up to date.

This reverts commit c89e308f.

This is not longer needed - with Zope 4 the ZMI is better and we now
have possibility to edit most of these through ERP5 user interface.
The main motivation is that these kind of patches are really hard to
keep up to date.

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.

Utility function taking care of the internal changes between RestrictedPython v3
and v5, keeping support for both (instead of having multiple if statements).