This reverts commit e50d05af.

* Zope API changes:
  + publish():
    - stdin is now BytesIO rather than StringIO.
    - Returned value of a script is passed to str() in python2, not in python3 anymore.
  + HTTPResponse `body` property is now bytes().
  + OFS.Image.File file parameter is bytes().
  + zope.interface implements() is now @implementer decorator.
  + Python standard logging module recommended instead of zLOG.
* Python3 API changes:
  + builtin reduce() was removed.
  + urlnorm is now available.
  + Use BytesIO rather than StringIO to follow py3 API.
  + hmac.new() requires digestmod argument from Python 3.8.
  + Use six.moves library to handle moved objects from py2 to py3.
  + `modernize -f xrange_six` then slightly adjusted manually to just use range
     where it does not make a significant difference (for example in test).
  + base64.b64encode() now expects bytes().
  + UserDict() interface changed:
    - New parameter in update() and pop().
    - `failobj` setdefault parameter renamed to `default`.
  + ensure_list() on dict.{values,items}() and list(dict) for dict.keys() when
    we really need a list and not an iterable (Python3).
  + Make dict iteration works on both version of Python.
    - Use six.iter{items,values,keys}().
    - has_key() has been removed.
    - Make sure that dict.{items,values,keys}() returns a real list when
    modified (ensure_list()).
  + Comparisons between int and NoneType raises TypeError.
    + BTrees key must be str() not int() (_getOb()).
  + No more unbound methods in python3 so use six.get_unbound_function().
  + Exceptions:
    - No longer behave as sequences. Using `args` attribute instead.
    - When an exception has been assigned using `as target`, it is cleared at
      the end of the except clause.
  + file: py2 was returning `str` upon reading, now it returns text strings.
    Also, opening mode is text strings by default.
  + Data strings are bytes().
    - Replace str() by bytes().
  + iterators no longer have next() method, instead there is next() builtin.
  + New ConnectionError exception so rename existing one to not clash.
  + Integer division is now with //.
  + __nonzero__ is now __bool__.
  + apply() does not exist anymore.
  + Deprecated threading.Thread isAlive() has been removed.
  + im_func replaced by __func__.
  + Use six.with_metaclass() to define metaclass in a cross-compatible way with py2 and py3.
  + Only test method can be marked as expectedFailure(), not assert statement anymore.
  + os.path.walk() removed.
  + HTMLParser never fails: no strict mode nor HTMLParseError anymore (Python #15114).
  + Unpickler.find_global() is now Unpickler.find_class().
Co-Authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>
Co-Authored-by: Arnaud Fontaine <arnaud.fontaine@nexedi.com>
Co-Authored-by: Carlos Ramos Carreño <carlos.ramos@nexedi.com>
Co-Authored-by: Emmeline Vouriot <emmeline.vouriot@nexedi.com>

Improvements compared to the previous implementation:
- avoid looking up the user document again, when the PAS plugin already did
  that job
- make it possible to call a single script when multiple sources of groups
  are based on the same documents, avoiding iterating unnecessarily on
  those same documents multiple times
- avoid repeating the same membership value (ex: when a user has multiple
  assignments with a common membership subset)
- avoid resolving the same relation more than once
- do not go from document value to relative URL only to go from relative
  URL back to document value at the next step
- move security group id extraction to unrestricted python, as the security
  overhead was taking a large amount of time
In a security setup with 8 scripts (all Assignment-based), 6 base
categories, and 4 Assignments (all valid), this implementation is 10 times
faster at producing the same group id set as the previous one.

This solves a failure with testBudget, it should only impact test, but
it's probably better to have a deterministic ordering here.

It is easy to see contents ordered by id by default in ERP5Site.

Products.CMFCore's version 2.7.0 of portal_url.getPortalObject
returns the portal in an incomplete acquisition context, which
causes issues when the site is registered as ISiteRoot utility
(the typical error being AttributeError REQUEST)

ERP5Site.getPortalObject works just fine and is used in many
places, this commit replaces all occurences of
portal_url.getPortalObject by getPortalObject.

Some old ERP5 site were registered as ISiteRoot and this cause
issues with Products.CMFCore update 2.2.10 -> 2.7

This reverts commit 035d099a.
Installing BTs which do not come from produt/ERP5/bootstrap breaks site
creation, except in unit tests.
This commit is very desirable, but not ready, so unfortunately I have
to revert it.

So every new instance is able to use self-contained oauh2 authentication.
In turn, this triggers atomated migration of a few portal types, which
cause the coding style tests to fail. So commit these as well.

Replace CookieCrumbler's cookie with OAuth2 tokens:
- add the notion of authenticated sessions: period from a login action to
  either a logout or the expiration of tokens
- avoids session fixation (knowing one token does not grant near-permanent
  access to the session)
- reduces the per-request cost of authentication (removes the need to
  compute user's groups, and the need to cache these groups for a fixed
  period).

done with:

    find product/ bt5 -name '*.py' | xargs -n 1 sed -i 's/ *$//'

Instead of hardcoding categories group in TradeModelPath, introduce
two new groups (as planned in the XXX comments) to list source
and destination arrow base categories.

...for  getPortalDataConfigurationTypeList.

See nexedi/erp5!1630 (comment 159889).

Done through various 2to3 fixers (zope.fixers, modernize, future) and manual
changes. This is a single commit so that we have a clearer picture of how code
converted with my2to3 should look like.

Except straightforward @implementer decorator 2to3 fixer, only product/ folder
was considered as the goal was to be able to create an ERP5Site.

* Use @implementer decorator introduced in zope.interface 3.6.0 (2010):

  The implements syntax used under Python 2.X does not work under 3.X, since it
  depends on how metaclasses are implemented and this has changed. Instead it
  now supports a decorator syntax (also under Python 2.X).

  Applied thanks to 2to3 `zope.fixers` package.

* Use `six.moves` rather than `future` install_aliases() feature because the
  latter use unicode_literals and "wraps" module aliases so that unicode() are
  returned for text rather than str() (Python2 standard library). This notably
  breaks BusinessTemplate code which uses urllib quote() for filesystem paths...

* No more unbound methods in python3 so use six.get_unbound_function().

* dict.(iteritems,iterkeys,itervalues)() => six.\1(dict) thanks to `dict_six`
  2to3 fixer from `modernize`:
  $ python-modernize -w -f dict_six product/

* Manually make sure that dict.{items,values,keys}() returns a real list when it
  is latter modified rather than a dict_{items,values,keys} (ensure_list()). By
  default, 2to3 blindly does list(dict.{items,values,keys}()) which is not
  acceptable from performances point of view. With my2to3, this will be possible
  to handle such case automatically.

* Replace cStringIO.StringIO() by six.moves.cStringIO() (a module alias for
  cStringIO.StringIO() on py2 and io.StringIO() on py3).

* Use six.text_type which maps to unicode() on py2 and str() on py3. This also
  makes a clearer difference between text and binary strings.

* Replace map()/filter() with lambda function by list comprehension (this has
  the benefit to avoid casting to list for py3 as it returns iterators).

But make it non-publishable.

Also, use it in Products.ERP5Type.tests.ERP5TypeTestCase.

This also moves all Configurator Workflows in workflow_module to portal_workflow
(workflow_module was an implementation of Workflows based on ERP5 objects and
not using DCWorkflow code).

* Workflows are now defined on on portal_workflow._chains_by_type anymore but,
  as everything else, on the Portal Type itself.
* portal_workflow can contain and work at the same time with legacy and new
  Workflows (ERP5Type/patches/DCWorkflow.py monkey-patching DCWorkflow classes
  to provide the same API).
* Existing Workflow Scripts should work as they are and the code can be updated
  later on to take advantage of the new API:
  + With legacy implementation Workflow {Scripts,Transitions,Worklists,States}
    were in a Folder ({scripts,transitions,worklists,states} attribute) but
    all of these are now in the Workflow itself and their IDs are prefixed
    (PropertySheet-style), for example `script_`. Legacy attributes are
    provided in new implementation to call the new API.
  + When calling a Workflow Script, `container` was bound to its parent, namely
    WF.scripts (Folder) and a Workflow Script could call another. Now `container`
    is bound to the WF itself and Workflow Scripts are in a Workflow directly.
    New implementation `scripts` attribute handle such use case.
  + Override portal_workflow.__getattr__ so that a Workflow Script can call
    another one without prefix.
* Worklist are Predicate: Worklist filter objects based on given criterions and
  thus it makes more sense for a Worklist to be a Predicate (albeit a Predicate
  with only Identity Criterion and nothing else).
  + Criterion Properties:
    * state_variable.
    * local_roles (SECURITY_PARAMETER_ID).
    * Any Workflow Variables with for_catalog == 1.

erp5_performance_test:testWorkflowPerformance were ran to compare DCWorkflow
and ERP5Workflow implementations and it seems to be about 4% slower with the
new implementation (legacy: 7.547, 7.593, 7.618, 7.59, 7.514 and new: 7.842,
7.723, 7.902, 7.837, 7.875).

Work done by Wenjie Zheng, Isabelle Vallet, Sebastien Robin and myself.

Portal is the Skinnable object, skin magic belongs there.

testUpgradeInstanceWithOldDataFs: Upgrade erp5_upgrader too (it was in keep
list until now) as old Data.fs contains ERP5UpgraderUtils Extension with import of
Products.ERP5Type.Log. Although, erp5_upgrader should probably be automatically
upgraded before even starting the upgrade...

Besides migrating Tools .py, this also moves the Tools themselves (portal_*):
 * Some of them were created before erp5_core being installed and this
   would not work anymore as their .py is now in erp5_core.
 * Some others were created after (via setupLastTool()) and this would not
   work neither as sub-objects may be installed by erp5_core.

Add them to template_keep_path_list to prevent them from being re-created like
ERP5Site.addERP5Tool() used to do (depend on 3180424b, 91393be2).

Not migrated:
  * AlarmTool: Needed for upgrader.
  * CategoryTool, IdTool: Bootstrap.
  * TemplateTool, TrashTool: Business Template installation.
  * SolverTool: TypeProvider.
  * ContributionTool: Imported by Products.ERP5.Document.Document used in many places, will be done later.
  * NotificationTool: Imported by ERP5.Document.EmailDocument, will be done later.

Since 7b4a3d4c instead of subscribing after add code unsubscribed which is illogical. Revert back. Credit Kaz.

business template update this code is called (with update=True argument)
and thus it will effectivly override previous portal_alarms' state which
is wrong as no "general purpose" code should ovewrite potential
developer configuration.

Make ERP5Type.Base and ERP5.ERP5Site inherit from it.

... so that queryUtility can later access the correct ones.

Note: we do not necessarily want to register all tools.