See merge request nexedi/erp5!1643

of Organisation_viewFinancialInformationList

In xhtml_style, just after clicking next or previous page in the listbox
buttons, the values selected in 'Section Category' and 'Section Category
Strict' were not used, because they were used from request and not from
as normal script parameters.

This fixes only the xhtml_style version, ERP5JS has another problem that
dialog fields values are reset when going to next page, so it would also
need this problem to be fixed.

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)

This is supposed to fix "Should not load state for ${oid of a skin} when
the connection is closed" sometimes happening with live tests (especially
when the test self.publish and the developer access the site while the
test is suspended on a debugger breakpoint).

The object accessed after the connection is closed was a skin (python
script, sometimes page template or form) that was cached in SKINDATA.
The mechanism to prune entries from the cache uses REQUEST.hold API
which expects that REQUEST.close is called on request, but because
requests were not closed at the end of the request, it happened that
the cache was reused from another connection.

This change to close the requests, like ERP5TypeTestCase is doing in
tearDown (the actual close is done by Testing.ZopeTestCase.connections).

By closing requests at the end of tests, we also have to change so that
at the beginning of the test we initialize the request, by using the same
setSite and setupCurrentSkin that are done in ERP5TypeTestCase.

This reverts commit 3db20ae6
and commit 948d8b57.

This commit and the fixup were not good, reverting to make a proper
commit

_Z2HOST / _Z2PORT no longer exist in Zope4, something was added in
component/egg-patch/Zope/0001-OFS-XMLExportImport.patch in SlapOS
software release, but we never had a strong need to patch there, we
were doing this so that Testing.ZopeTestCase.utils.makerequest creates
a REQUEST to this host:port, but now that Zope's startZServer no longer,
the REQUEST created by Testing.ZopeTestCase.base.app is always to
nohost:80, so we need to rewrap the app in request to our host:port.

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 )

_Z2HOST / _Z2PORT no longer exist in Zope4, something was added in
component/egg-patch/Zope/0001-OFS-XMLExportImport.patch in SlapOS
software release, but we never had a strong need to patch there, we
were doing this (I guess) so that Testing.ZopeTestCase.utils.startZServer
knows that a server is already running and refuse to start another one,
but now that Zope's startZServer no longer exist, a local variable is
just fine.

Use correct portal type.