fixup! ERP5Catalog: Fix UnicodeDecodeError on non ascii catalog search when the inituser name is unicode

variable was not zope_testSearchNonAsciiWithLegacyUserFolderUser

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

This backports parts of zope 4 commits [bb7837c66 (Explicitly make all
classes new-style., 2017-09-15)](https://github.com/zopefoundation/Zope/commit/bb7837c66) and [173658008 (Fix unpickling of instances
those base class changed to a new-style class. (#208), 2017-10-24)](https://github.com/zopefoundation/Zope/commit/173658008) for zope2.

This is done for two reasons:
 - so that business template XML are same when exported from zope4
   and from zope2
 - so that a business template created from zope4 can still be
   installed on zope2.

See merge request nexedi/erp5!1596

This is used to trigger recompilation of bytecode, but we don't
export the byte code so we don't need to export it.
This also prevent diffs when the Script_magic changed, like it's the
case with Products.PythonScripts 4.2 , with commit 590125a (Force
recompilation of scripts., 2017-10-23).

This is patched to DateTime.DateTime._dt_reconstructor but we don't
want _dt_reconstructor to appear in pickles, especially business
templates ones.

These properties are supposed to never be set on ERP5 documents.

See https://lab.nexedi.com/nexedi/erp5/blob/34f4ae37/product/ERP5Type/Constraint/PropertyTypeValidity.py#L65

This backports parts of zope commit bb7837c66 (Explicitly make all
classes new-style., 2017-09-15) and 173658008 (Fix unpickling of instances
those base class changed to a new-style class. (#208), 2017-10-24).

This is done for two reasons:
 - so that business template XML are same when exported from zope4
   and from zope2
 - so that a business template created from zope4 can still be
   installed on zope2.

This properties are not used, no need to have them exported

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

If there's an error during the --save setup, we don't need to run
the --load steps, because test failed already and if they don't
fail in --load step, it would be a case where some errors are not
reported.

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.

This reverts commit c45c2295.

to get test passing again

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)

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