Because unlike `getFoo()`,  `getProperty('foo')` does not checks the permission defined on the accessor, when a form contain a `my_foo` field, the property would be displayed to the user who can view the form, even if the user does not actually have the permission to get this property. This because getter for default value of fields uses getProperty ( [here](https://lab.nexedi.com/nexedi/erp5/blob/58d4ab8efef748f522b3eaaecba3dc1133c99e72/product/ERP5Form/Form.py#L275) ).

These changes modify behavior of `getProperty`, so that it enforces read permission security of properties and raise when user does not have permission to access properties.

Some notes about implementation:
 * `getProperty` now becomes a bit slower, but it was incorrect before, so I guess it's inevitable.
 * some efforts have been made to keep the impact on performance minimal. This uses the same approach of  in `edit` of computing the set of restricted properties and using `guarded_getattr` only on these properties and using `getattr` on non-restricted properties. The computation of this set was moved  to dynamic class generation time and as a result, `edit` becomes a bit faster.
 * the `expectedFailure` part of `test_PropertySheetSecurityOnAccessors` was moved to another test, but I'm not even sure we want to support this (read-protecting properties with default write permission) as, to me, such configuration does not make much sense. 
 * new performance tests were added. I don't know what to use as min/max values so I just used something that should pass.
 * implementation for `getProperty('*_list')` was changed a lot, I have no idea why this was getting the method on the class and passing self as first argument. Now it we just get method on the instance, like we do for single properties.

/reviewed-on nexedi/erp5!181

all repository list which will cause a mismatch between test suite class
location and repository.

/reviewed-on nexedi/erp5!945

/reviewed-on nexedi/erp5!944

bt

This reverts merge request !916

Merged by mistake

/reviewed-on nexedi/erp5!942

This reverts commit f9f020e3.

Assuming that the test database already exists and 'movement' table already
contains data (from past execution for example), on '--save' before this
commit:
  1. Create a new ERP5 Site:
     1. Install erp5_mysql_innodb_catalog.
     2. Call ERP5Site_reindexAll(clear_catalog=True) (from ERP5Generator.setupIndex()).
        => At this point, erp5_mysql_innodb_catalog tables are recreated.
  2. Install erp5_movement_table_catalog or any bt5 adding a new SQL table.
     => This does not recreate the table and leave the existing data as it is.
  3. Dump MySQL database to dump.sql.
  => dump.sql contains 'INSERT INTO' for 'movement' table *before* this '--save'.

This fixes random customer Unit Tests failures on SQL queries accessing
'movement' table directly and getting {non-existing,past executions}
Movements.

Fixes, refactoring, details and more app migrations.

/reviewed-on nexedi/erp5!916

This reverts commit b6b517ee.

which impacts "Time Table Line" and "Public Holiday Line" portal tyle
I need to check more portal type before remerge it

This field was only displayed if any of these was enabled:
 - by function analytics
 - by project analytics
 - by category analytics

and it allows requesting reports per function, project, categories and
section.

The problem is that if any analytics was explicitly enabled, we never
allow users to get a break down by section.

Always display the field, so that user can always select section.

This does not make much sense when there's only one section though.

/reviewed-on nexedi/erp5!939

Before this change, class hierarchy is like this when using mixin:
```
class MyClass(BaseClass, Mixin1....)
```
which is usually ok when classes don't override each other's

But if we want to overwrite BaseClass's method by using mixin to do more thing,

For example:
```
class BaseClass(object):
  def test(self):
    print 'base test'

class Mixin1(object):
  def test(self):
    super(Mixin,self).test()
    print 'mixin'
```
I want to display 'mixin base test' when call test, but it doesn't work

since priority of how methods are resolved is from left

to right: BaseClass----->Mixin1, it only display 'base test'

So the correct way to use mixin should be in reverse order:
```
class MyClass(Mixin1, BaseClass)
```

/reviewed-on nexedi/erp5!935

When other nodes takes time to start they are not always registered
when the "main" node asserts that they are there.
We observed problems in an environment where resolving localhost (by
DNS) takes 10 seconds.

Also introduce getOtherZopeNodeList utility method that can be useful in
other ZEO tests in ProcessingNodeTestCase

When other zope nodes takes time to start this sometimes causes
conflict.

Reset mailhost before each test.

Commit changes created by portal_transforms.

This allows restoring the correct skin selection in ERP5JS.
Deferred reports can now be used in ERP5JS.

REQUEST is used to support direct form rendering, like: ./Base_viewHistory?deferred_portal_skin=ODS&portal_skin=Deferred

Thanks to Georgios Dagkakis for his work on this topic.
See nexedi/erp5!702

- corresponding test update