Since a29456bc, only import lock is used instead of aq_method_lock, dynamic
modules locks and import lock. However, it was creating another deadlock:

when the import lock is held in one thread (for instance when trying to
perform migration to Portal Type as Classes and ZODB Property Sheets), and an
object is loaded from ZODB, a request is sent to ZEO, and this blocks until
another thread (asyncore) gets the ZEO reply and sends it back to the first
thread.

However, if the asyncore thread receives an Exception, it will tries to import
its module and thus create a deadlock as the import lock is still held by the
first thread.

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.

This has several benefits:

* No need to exit maximize/fullscreen modes to save.
* The cursor position in the editor does not change.

This implementation is hackish because it is too Component-specific, but until
RenderJS is being used, there is no probably no better way.

How it happened while upgrading PathTemplateItem:
  1. Tries to remove the existing broken object and succeeds removing
  2. However it is a broken object so self.unindexCatalog() is
     never called and the old catalog is remaining
  3. Add new object of PathTemplateItem and tries to reindex the object
  4. Since old catalog is remaining, the catalog uid and object uid is
     different so catalogObjectList fails with FATAL error.

The test is tests/BusinessTemplate.py#test_UpgradeBrokenObject.

Workaround fix for translated_simulation_state_title. Use translated_simulation_state_title__ column when translated_simulation_state_title is sorted because translated_simulation_state_title is a scriptable key and it is not sortable.

ZODB Components: Developer Role was not returned by getRoles() for users added through erp5.acl_users.

It was only working if the user was only in Zope acl_users but not ERP5
acl_users because getRole() was not monkey-patch in contrary to AccessControl
BasicUser.

TODO: Add unit test before merge.

* Current user must have permission to add Components in portal_components.
* bt5 must not be in installed state as this script updates bt5 properties.
* There must be some Extension, Document, or Test not already migrated.

development mode because there was a check whether Extension on FS should be
reloaded even for Components.

This reverts the following part of 5d9c30e:

* Upon bt5 installation, install portal_type* items before bt5 {Document,
  Extensions...} as corresponding Portal Type are required once they have been
  migrated to ZODB Components.

This obviously does not work as the Document can be used as Type Class and
also because tool_item is required before portal_types for example (see
test_type_provider).

When bootstrapping erp5_core and installing for example an Extension
Component, this will try to load Extension Component Portal Type which does
not exist yet but fallback on its document class instead, which is enough
until Extension Component Portal Type is installed.

In 5d9c30e, Permissions were set in ComponentTool __init__ and it could not be
modified later on because it is set directly in the ZODB. Moreover,
Permissions could be modified after execution by modifying attributes.

Folder_delete calls Workflow 'delete_action' if the object has any Workflow
History. Before, component_validation_workflow was acting like
validation_workflow for deleting objects, e.g. 'delete_action' triggers
'delete' state which is fine for normal documents but not Components.

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.

Only erp5_trade, erp5_core, erp5_administration and erp5_base for now.

* Upon bt5 installation, install portal_type* items before bt5 {Document,
  Extensions...} as corresponding Portal Type are required once they have been
  migrated to ZODB Components.

* Likewise portal_{property_sheets, types}, portal_components must be created
  automatically *before* installing any bt5. This is required when Products
  will be migrated but also for bt5 items before bootstrapping erp5_core bt5.

* Set Permissions in ComponentTool instanciation and revoke all permissions,
  then allow only some of them for security sake.

* When creating ERP5 site with unit tests, add ERP5TypeTestCase to Developer
  Role ASAP so that there is no Permission issue when installing bootstrap bt5
  and test bt5s containing ZODB Components.

This will not work when there are several nodes anyway, so just display a
message to the user instead.

Also, upon installation of bt5s, install WorkflowItem before Components as it
is needed to restore history.

Another solution would have been to validate() ZODB Components automatically
upon bt5 installation but it would mean losing 'modified' state information
and also imply that *all of them* will be validated even if a developer wants
to publish non-validated ZODB Components.

getattr() will never load the Component, whereas import does. Also, unit tests
were passing with this bug, so improve unit test so that asserting that a
module is importable does not have side-effects.

For now, just ignore it but it may be required later to define dummy accessors
so that the registry and Components can be loaded even when their accessors
are not generated yet.

It is exactly the same at the end but the name of the latter does not make
sense in this context. Moreover, it allows to get rid of Base import.

If PATH environment variable is not defined, this Products cannot be
imported. Followup of 399f95f9.

banking bt5 which override z_catalog_stock_list.

Just copy z_catalog_stock_list.xml as the new Z SQL method in banking bt5 as
it does not make sense to have more than 300 Inventory Lines in this case.