This reverts commit 00e8d126.

See commit c45c2295
("erp5_web_shadir: more useful checks").

This fixes how the builder processes the result of IMovementGroup.test.
Testing deliveries to find one that can be updated should have no impact
on properties if the builder ends up creating a delivery.

When i upgrade/install erp5_notebook in an instance which use neo storage instead
of zeo, Neo stopped immediately, as consequence, erp5_notebook can't be installed/upgraded.

The reason is in erp5_notebook, there has a one big file scipy.data.bin 157MB [1] which can't be
installed as it is  in neo. The solution suggested by @jm is to wrapper it by Pdata when install
a BT5.

See merge request nexedi/erp5!953

[1] https://lab.nexedi.com/nexedi/erp5-bin/blob/7d3505fd/bt5/erp5_notebook/SkinTemplateItem/portal_skins/erp5_notebook/scipy.data.bin

In 44e0b22f (Move to new API, detailed properties take precedence,
2011-09-09) we introduce a new data model for coordinates, in the case
of emails, we have "url_string" fro the "detailed" form and
"coordinate_text", for the "store what user entered" form.

In some places of erp5_credential, we use setDefaultEmailText, which
calls Coordinate.setText which uses the deprecated Coordinate.fromText,
which sets the same value for "url_string" and "coordinate_text", which
seems a questionable behavior, because the data is saved twice and
some code might be using the wrong property.

This changes every usage to the new coordinate_text property

Update ZMI pages with the design of Products.ZMySQLDA and with the
usage of manage_page_header, which sets the content-type to html

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