After adding document component object, _p_oid was bing generated at the
last step of commit hook. This led to problem that _registry_dict for
dynamic_class 'erp5.component.document' wasn't getting updated with
the _p_oid of the component created. This led to failing of test because
to validate object with same reference, the checkConsistency function
checks in the _registry_dict for reference and _p_oid.

Explicilty calling commit here generates the oid before validation, hence
make it available for the registry_dict in time.

But, this clearly is a workaround which is clearly not solving the real
problem of why the _p_oid isn't being generated at the right step.

Also, me(Ayush), tried to recreate this error on a running instance, but
it worked fine there.

Earlier, class for any Catalog object used to be Products.ZSQLCatalog.SQLCatalog,
but now as we have shifted SQLCatalog to ERP5Catalog, the catalog objects have
lazy_class 'erp5.portal_type.Catalog' as their 1st class in mro. This class
don't have the required attributes.

The lazy_class is dynamic, so its not possible for them to save reserved IDs
as their attributes. So, we use the next class in mro, which would be
class 'Products.ERP5Catalog.ERP5Catalog' and save attributes in it.

Notice that this change of 'self.__klass__' is not required if
we are starting a lock with '_reserved_uid_lock' and then acquire-release it
consicutively in one go(transaction).

Create FilterDict and Filter class which would be used to imitate the behaviour
of filter_dict for Catalog.

/suggested by @jm

And, Patch changeObjectClass extension to remove useless attributes

Copying __dict__ from one object to another brings us to situation where
we don have many objects which we don't need at all, for example, migrating
objects with subclasses who were initially OFS objects and later an ERP5
object can lead to adding subobjects as attributes of the new object, which
is completely undesirable. To handle this, it is important to delete the
sub-objects as the attributes for those migrated classes.

erp5_catalog: Refactor _bootstrap for Catalog Tool

Old Catalog Tool didn't have portal_type attribute, so while migrating
via synchronizeDynamicModule, after _bootstrap, we expect the tool to
have a portal_type to finalize migration.

This step is now being done only at the end of _bootstrap after we
change the classes for portal_catalog and its sub-objects.

And, changes to improve performance while dynamic migration.

XXX: Still at this point we are not doing the same thing with
sub-objects of catalog tool and wait till business template
installation.

erp5_catalog: Update attributes of the portal_catalog object after migration

One of the difference between SQL and ERP5 Catalog is how they
handle their properties. For ERP5Catalog, we use property_sheets
which generate setters and getters, for SQLCatalog, properties
just act as attributes(as one can expect from a property set
on a class).

This creates a difference on how we use them, especially for
list_type properties, which have accessors like get<PropertyName>List
to get the list of objects. For SQLCatalog, there is no such thing.
This creates problem whereever 'get<PropertyName>' or getProperty(<name>)
was being used to get multiple property types.

So, we changed this to rely on getattr for the Python Scripts in this
commit. Note that, getattr isn't good if we care about performance,
but given that its used only twice, this can be better than adding
extra function overhead.

Also, add test for migration in testERP5Catalog(as the first test to be run)
and migrate Catalog in afterSetup in testERP5CatalogSecurityUidOptimization.

Use filter attributes as property. Same as done for ERP5 SQL Methods.
This way maintains consistency between sub-objects of Catalog, i.e,
SQL Method and Python Script.

This removes the need to copy-patch or if-else on meta_type of catalog.
Use dynamic migration while installing the catalog method objects for
bt5.

Contains views, property sheets,  portal types concerning migration of
portal_catalog, sql catalog and their subobjects to erp5 object.

Portal Types:
1. Catalog : ERP5 Catalog object (an ERP5 Folder), which earlier used to be OFS Folder.
	Actions:
		Update Catalog
		Clear Catalog
		Clear Reserved
		Export Properties

2. Catalog Tool: Portal Catalog where we can add and use multiple ERP5 catalogs.
	Actions:
		Hot ReindexAll

3. SQL Method: SQL methods with their views inside erp5.
	Actions:
		Run Method

Property Sheet:
1. Catalog
2. CatalogTool
3. SQLMethod
	Containing properties for the various portal_types/classes respectively.
4. CatalogFilter

Also, filter_dict for erp5_catalog would now not be a Persistent Mapping
object. The info inside filter_dict is being saved inside the SQL Method
objects as their properties.

Views:
1. Catalog (View)
2. CatalogTool(View, Properties, Filtered Items), Object Actions
3. SQLMethod (View, Filter)
4. Python Script (Filter)

Extras:

	- Dialog view for catalog before clear_catalog

	- Add typeBaseMethod(s) for PythonScript and SQLMethod portal types:
The methods <portal_type>_getRedirectParameterDictAfterAdd are required for these
portal_types, cause their __call__ methods are overridden, so after addition
of new objects for them, it was taking to the url concerning wherever __call__
methods directed them.
Now, we change them to redirect to 'abosulte_url+'/view'' which is basically
the homepage for these catalog methods.

	- Do not use default ERP5 Catalog to show properties:
Earlier, in tales for properties for any erp5 catalog, we showed
the values for the default_erp5_catalog. But keeping in mind that
we can have multiple catalogs at same time, the old approach
was wrong. Hence, we now display properties for the current catalog

	- Search fo Catalog_viewContentList and Catalog_viewFilterList

Its better to change the tests where they need to call getpath function of
portal_catalog to use portal_catalog.getpath instead of portal_catalog.getPath,
as we have overridden the 'getPath' function for CatalogTool class due to change
in inherited class.

- This step is needed due to the use of BaseTool as Base class for CatalogTool
  due to which there were conflict between reindexObject from the Base and the one
  from the BaseTool.

	- Remove copy-pasting all code from CatalogTool, better to rely on inheritence
	- Remove unnecessary imports
	- Add argument id in __init__ class
	- Add functions _isBootstrapRequired and _bootstrap
	- Update BusinessTemplate installation according to changes made in ERP5Catalog and Tool
	- Explicilty add manage option tabs in Catalog Tool

Move from SQLCatalog to ERP5Catalog as the default Catalog inside ERP5.
The major difference is use of Products.ERP5Type.Core.Folder as Catalog
base class.

Significant changes:
	-Inherit from Catalog class from Products.ZSQLCatalog.SQLCatalog instead of copy-pasting the whole code again.
	-Add allowed_types for ERP5Catalog tool
	-Monkey patch some property setters and getters to maintain consistency
	-Update id and title for ERP5Catlog while class initialization
	-Set declarative securities and solve some inheritance conflicts
	-Add isRADContent for ERP5Catalog Class
 	-Solve inheritence conflict for _setPropValue function in ERP5Catalog class
	-Add SQL Method portal_type in allowed_types for ERP5Catalog class
	-Override getCatalogMethodIds cause it uses global variable in SQLCatalog.Catalog
	-Redefine security declarations
	-Add functions for object_actions of Catalog portal_type in ERP5Catalog object
	-Add filter_dict and _properties attributes for compatibilty

Create the SQLMethod class based on ZSQLMethods.SQL
class and XMLObject. Also, move attributes to
property in 'SQL Method' property sheets.

These methods will be used in erp5 catalog view in restricted environment.
Loosen the security on methods which we will use in erp5 catalog view in
restricted environment. As suggested by \@vpelletier, this should be
accepted as all methods were restricted by default earlier.

And, change in files where this was being used

Earlier, In ERP5Site, we use property 'isIndexable' to have control over indexing and unindexing.
This was usefull specially in case of bootstrap. To have this control, we had a function
`isIndexable` in SQLCatalog which we used to switch for enabling-disabling indexation. (769f9fb2)

This is a preparative commit for case where:
Now, as we move to ERP5 based Catalog, which itself is an ERP5 Object, hence it has an accessor `isIndexable`
of itself which we plan to disable for now(as we don't want circular dependency while indexing
catalog in itself). But as we did have a function `isIndexable` in SQLCatalog which had control
over the indexing, we needed to rename this property for ERP5Site.

Hence, now we use property 'isIndexingRequired' for ERP5Site and use to have overall control
over indexing process.

Please note, we do not intend to change the same property name for any other object. Its just
for ERP5Site.

This would also remove the need of evaluating the globals every time.

to fit original script behavior, from erp5_web skin folder.
Also fixes "KeyError: TraversalRequestNameStack" from
`WebPage.getDocumentValue(reference)` on the "View" skin selection.

To make it easier for users to change their preferences, so that they do not have to create the preference themselves, we tried to pre-create a user preference ready to be configured for each user.  

It was 59860df3 :  an interaction to create a user preference on `Person.setReference` which is more or less the time when this person become a user ( but not really - this was already a weakness of this approach).

This calls `Person_createUserPreference` that initialize the preference by introspecting the assignments of the person. This already had a problem that it was working only if the assignments were created before the reference was set on the person.

With the new user management introduced in !185 this interaction moved to `Person.setUserId`, which is called in Person's init script. This had the following problems:
 - All persons have a user id, so all persons have a preference. For sites with many persons that are not actually users, this create useless preferences.
 - During init, person does not have assignments yet, so `Person_createUserPreference` could not use information from assignment to create preference.

The suggested change is to create the preference only when the user click on *Edit my preferences* button.

This is done by adding a new `portal_preferences.getActiveUserPreference` method that returns the active user preference and create it if not already existing, this way we do not have to put logic in the user interface scripts.

All *Edit my preferences* links should use it like it was done in f62e6651

The `person_interaction_workflow` was completely remove, as the other interaction it was containing - clearCache when deleting the person - was useless . We had to adjust a few tests that was passing thanks to this interaction.

/cc @gabriel @vpelletier @kazuhiko @tc 

/reviewed-on nexedi/erp5!273

Base.edit has this feature of not actually modifying the properties when
the new property value is same as the current one, so when we do
`movement.edit(price=x)`, this will cause an implicit getPrice.

As price lookup is a bit slow, do not lookup price in this case.

/cc @vpelletier @kazuhiko @romain 

/reviewed-on nexedi/erp5!259