This is still a work in progress

The action to recreate activity tables while preserving existing messages
was unsafe for 2 reasons:
- if any error happened, messages could be lost
- it relied on Message.reactivate

Which this patch, any instance created after commit d881edd1 (Aug 2010) will
upgrade successfully. For older instances, make sure you have no activity left.

For cases where 'ALTER TABLE' would not work, a better way to implement repair
functionality would be:
- one action to backup all messages in ZODB
- and another to restore them
And maybe a security so that during the backup-clear-restore sequence,
activities can't be created nor processed.

If any column is added in the future, it would still be possible to write code
that fills them by inspecting messages.

MRP was broken and unused for a long time, since legacy simulation was dropped.
This commits resuscitates MRP, at least:
- expanding, for both operation and sourcing
- building of production reports & production packing lists

Business Processes replaces Supply Chains.
trade_phase replaces industrial_phase
industrial_phase is now used to variate partially produced resources.

Calendar Assignments are now handled in a separate module, update
code in consequence

other ZEO clients even if ZODB Components are not.

Steps to reproduce:

  1/ On zope1, view and edit a person to make sure class is fully loaded.
  2/ On zope2 add an interaction in person_interaction_workflow and add a script raising an exception.
  3/ Edit a person on zope2. The exception is raised, confirming that the interaction is called.

  When editing a person on zope1, the exception is not raised.

ZODB Components: No need to migrate Component Tool, only exist since Portal Type as Classes and ZODB Property Sheets.

Because of recently added Component Tool, POSKeyError exception was raised
when trying to load it from ZODB during migration of Portal Type classes and
ZODB Property Sheets (PickleUpdater() in ERP5Site.migrateToPortalTypeClass),
so make sure that there is a commit before loading anything from ZODB.

Before, it was in Site _local_properties, but as this is stored in ZODB, old
sites would not have this property and would thus not allow to modify it
through 'Properties' Site tab.

When starting a node, ERP5Site.__of__ calls ComponentTool.reset(), which was
never synchronised so it returned True (without generating a new cookie at its
level) and causing synchronizeDynamicModules to be called with
force=True. This generated a new cookie and leading to dynamic classes being
meaninglessly regenerated on all nodes.

Instead, modify ComponentTool.reset() behavior so it *always* reset Portal
Type classes when Components are reset (as it should have always been as the
class inheritance may have been modified) and force regeneration of Portal
Type classes in this method if reset is True.
Signed-off-by: Vincent Pelletier <vincent@nexedi.com>

This reverts commit 6fc11699.
Some test fails, please review

Since erp5_xhtml_style has become requiring erp5_jquery. (in reality required since 2010)

Complete rewrite of the syncml core engine to make it scallable
Remaining work :
- review of conflict management
- re-implement splitting of big object
- generic unit test for AsynchronousEngine
- complete review of default conduit
- lot of TODO and XXX in the code to check

... instead of relying on automatic migration.

This fixes TestCMFActivity.test_connection_sortkey on Zope 2.13

Sometimes on configuration product-config can be defined but promise-path and
site id isn't, like for example when some instance use DeadlockDebugger.

Whitespaces shall be encoded with %digit

  Read external promise parameters.

  The parameters should be provided by an external configuration file.
  Location of this configuration file is defined in the zope configuration
  file in a product_config named as the path of the ERP5 site.
  Example if the site id is erp5:
    <product-config /erp5>
      promise_path /tmp/promise.cfg
    </product-config>

  The promise configuration is a simple ConfigParser readable file (a list of
  section containing a list of string parameters.

  getPromiseParameter returns None if the parameter isn't found.

Also, use local imports of itools where this is still necessary,  and remove all mention of itools from ERP5 code.

They duplicate [gs]etDefaultActivateParameterDict on ActiveObject.

Also, declare ERP5Site.getVersionPriorityNameList() as protected rather than
private for views.

This is similar to portal skins priority, except that versions and priorities
are defined on ERP5Site (as 'VERSION | PRIORITY' where PRIORITY is a float) as
there is not one Folder for each version in contrary to portal skins.

On the Business Template itself, versions and priorities can be defined like
'VERSION | PRIORITY' or simply 'VERSION' (where PRIORITY is assumed to be
0.0). Upon installation, it will be merged into ERP5Site property in
descending order (by priority first and then by version for versions with the
same priority).