Therefore, all Test Components are now ERP5TypeLiveTestCase. For backward
compatibility sake, just modify Test Component class bases to
ERP5TypeLiveTestCase, likewise runLiveTest.

This means that tests ran through runUnitTest and from Live Tests ERP5 UI would
behave exactly the same, contrary to the implementation before Test Components.

Also, move a method called in one of ERP5TypeTypeMixin method from
ERP5TypeTestCaseCommandLine.

ZODB Components: Revert 'Allow to execute runUnitTest for bt5 Test Components' (a771dca4) to fix tests bootstrap.

The new syntax to load ZODB Tests Components is:
runUnitTest BT_TITLE:TEST_NAME

That commit was too adhoc as it was relying upon filesystem to load Tests
Components and was not behaving like any other Components (versions was not
available and other Components were not importable).

At the end, it would have meant that a Test Component ran through runUnitTest
and Live Tests (in ERP5 itself) would have behaved differently, thus instead:

1/ Install BT_TITLE dependencies and its test dependencies (new bt property to
   specify bt to be installed only for tests on a fresh instance).
2/ The site is loaded.
3/ Load the test by importing it like any other Components.

Avoid an extra step for developers by keeping the last Workflow History for
Components by default.

Considering erp5_configurator_ung depending on erp5_configurator which in turn
depends on erp5_workflow, if erp5_workflow and erp5_configurator_ung are
specifically added to the list of bt5 installed with depends, then erp5_workflow
ended up being installed *after* erp5_configurator.

Usage: runUnitTest test.VERSION.REFERENCE as exported on the filesystem. Also,
add bt5 Test Components to tests being run through erp5testnode.

updated after removing global actions (83a994b7).

Also, fix erp5_email_reader bt5 definition for actions never committed.

ZODB Components: Component with the same version/reference as a validated one must not be able to be validated.

Only the source code and the last workflow history is actually relevant, so
remove all Workflow History except the last one to minimize diffs.

This adds a property to BusinessTemplate for generic behavior, overriden for
ZODB Components to ignore all Workflows except component_validation_workflow.

Tests may login/logout with different users. This fixes
testDynamicClassGeneration.TestZodbTestComponent.testRunLiveTest.

ZODB Components: Only Manager or Developer Role should be able to access Component Tools and Components.

Before, 'exec' was used but it is not safe as it executes the source code and
also not so useful as it stops at the first error. So, use pylint instead:

* Report errors and warnings (naming conventions could later be checked too).
* Allow to jump directly in Ace Editor to the message line/column by clicking on it.
* Define properly dynamic packages by setting __path__, otherwise pylint fails
  when a Component imports another one.

Also, split up consistency checking done in validated/modified state and
checking source code everytime the source code is modified:

  Source code error message was previously stored as a workflow variable,
  which didn't make any sense because user would only get error messages on
  Workflow transition, thus use existing Interaction Workflow to check source
  code and set newly defined error/warning properties everytime the source
  code is modified.

Otherwise, without passing the new height/width to resize() and without force,
text is not visible when switching to maximize/fullscreen mode.

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.

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.

* 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 aed4f303:

* 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 aed4f303, 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.