On Zope4 these settings are no longer in zope.conf

We now target transaction 3 so this patch is not longer compatible and
no longer needed according to discussions on the launchpad issue.

_sort_key is also set to '1' on recent Products.ZSQLMethods

For now, remove it completely. If necessary `registerHelp()` can be used.

  commit f3ab4409bfa9a3e1943099c8ae391a2f0273b53b
  Date:   Sat Jul 2 18:26:53 2011 +0000
    Removed the old help system, in favor of the current Sphinx documentation
    hosted at http://docs.zope.org/zope2/. For backwards compatibility the
    `registerHelp` and `registerHelpTitle` methods are still available on the
    ProductContext used during the `initialize` function.

Unlike StringIO.StringIO().tell() and open().tell(), which all return
int, io.BytesIO().tell() returns long. Because io.BytesIO is used when
uploading files on Zope4, this cause PropertySheetValidity errors when
checking consistency, because Data.size property is expected to be int.

Checks that created document types match constraints

Previously, we were using an encoded string, which in practice worked,
but with python3, WSGI server will encode as latin1 (because WSGI is
latin1) and already with Zope4 on python2 we have issues with testing,
as functional testing fake WSGI server only accepts ascii headers [1]

1: https://github.com/zopefoundation/Zope/blob/cddecf7e/src/Testing/ZopeTestCase/functional.py#L125-L126

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>, ...]

No longer needed on Zope4, from commit dc5b9292f (Merge pull request
 387 from zopefoundation/re-379-revert-repr, 2018-10-26)

Not handled by waitress:
  https://github.com/Pylons/waitress/issues/198

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

`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)

This drops some patches that should no longer be needed with zope 4 to
only keep the publisher timeout changes

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 )

TODO: I don't remember exactly but I think there was two failing
tests. Note that this test is in portal_components but running it
break the site so it's required to restart zope between each test
run.

remaining TODO: check the diff more carefully between the monkey
patches and the version from Zope. There are also some TODO comments
inline in this patch for things that are suspicious

In Zope4 error_message is sometimes not passed.

( also http exceptions are callable but that was fixed in
3cffb52c  xhtml: the exception in error_value is callable and evaluated, prevent it when rendering page [aurel]
maybe we can squash these two commits later )