Some test suites who install software during the test, such as SLAPOS-SR
tests, could benefit from reusing already installed shared parts.

The convention is that --shared_part_list is a os.pathsep (:) separated
list of paths of read-only shared parts in which the test is not allowed
to write.

Shared parts speed up compilation time and is becoming the standard in
SlapOS software installations, so it makes sense to use it in our test
nodes, as it also gives one more opportunity to test this feature.

erp5testnode configuration file supports a new shared_part_list option,
that can be set to a \n separated list of paths to use for shared parts,
following the same rules as slapos.core and slapos.recipe.cmmi (ie. the
first ones are read-only and the last one is read-write).

This shared_part_list option will be set in slapos.cfg used to compile
both the "software for testnode" (ie. selenium-runner) and later the
softwares under tests.
The software under tests will also use a local directory for each test
suite to install shared suite.

The directory structure is now:

  srv/
    shared/
      (shared parts to install selenium runner)
    slapos/
      soft/
        (selenium-runner software)
    testnode/
      foo/ # test suite with reference foo
        inst/
          (partitions of tested software)
        shared/
          (shared parts to install tested software)
        soft/
          (tested software)

and in the configuration srv/shared will be set as initial
shared_part_list.

When installing selenium-runner, srv/shared/ is used to write shared
parts. These shared parts are never removed.

When installing software under test, srv/shared/ and
srv/testnode/foo/shared/ are used. If parts are found in srv/shared they
are used, if they are not found, they are installed in
srv/testnode/foo/shared/.

In practice, this should mean that the shared parts installed by
selenium-runner will be reused for all tested softwares and this should
speed up initial installation of these softwares.

Currently, nothing is implemented regarding removal of unused shared
parts, but in our case:
 - srv/testnode/foo/shared/ will be removed when "foo" is removed.
 - srv/shared/ should be used only when installing selenium-runner.

If this starts to use too much disk space, one quick and dirty
workaround could be to destroy the test node instance and re-create it.

pkg_resources.resource_string reads the file as binary, if we want to
substitute in this string we need to decode it.

See nexedi/slapos.core@42b55b5f

Classes to hide the header or the footer of a Listbox in new render-js and the header in xhtml (since there we have nothing in the footer anyway)

/reviewed-on nexedi/erp5!947

/reviewed-on nexedi/erp5!934

- redirect to sync when app version changes
- fix configuration searchable fields in list form
- fix codemirror editor gadgetField
- fix exception catch in action script
- handle jio not found error for document

- document view
- upload and download

* Add erp5_core_proxy_field_legacy to dependencies (because of (at least) my_password).
* Rename ERP5ShortMessage.Errors module because the name is too generic for a 'Module Component'.
* Fix type_class of SMSTool: This should be the name of the class only, excluding the module.
* Add missing __init__.py to tests directory so that it can be migrated.

This is done by inheriting most of the code of ConflictFreeLog,
i.e. using a doubly-linked list:
- for fast iteration of the first elements, and in particular
  immediate access to the first element (used for creation date);
- that keeps track of the history length;
- that implement fast reverse iteration (although it could
  have been done without changing the data structure).

The size of buckets is not fixed anymore to 16 items:
like ConflictFreeLog, WorkflowHistoryList is also a good candidate
to look at the estimated serialized size of the bucket in order to
decide if elements should be added to a new one or not.
Then developers won't have to care about using Pdata or not.

The size is bigger than the ConflictFreeLog default,
because workflow items look a lot alike and adding
a few more is cheap when the ZODB compresses.

No more optimized __getstate__ (except for workflow histories that
have not been migrated) so BT export will be a bit more verbose.

The BBB code is because of
  nexedi/erp5!934

/reviewed-on nexedi/erp5!941

ZODB Components: Before migrating Interfaces from FS, there must be one Interface class per source file matching its name.

Same as Document class: this avoids registering Interfaces at startup and just do it
when using the Interface. In assuming that portal_components/XXX has a class
name equals to XXX.getRference(), it is easier to:
 * List all existing Interfaces (for example in Portal Type Class view): getReference()
   on all validated 'Interface Component' in portal_components.
 * Lookup for an 'Interface Component': 'from erp5.component.interfaces.XXX import XXX'.

ZODB Components: Properly handle addition of template_* properties in BusinessTemplate PropertySheet.

On the plus side, this avoids an ugly 'except AttributeError: pass' which does
not work anyway with the scenario below.

Assuming the following:
  * template_XXX Property (accessor: getTemplateXXX) recently added to BusinessTemplate PropertySheet.
  * erp5_YYY sets template_A Property (erp5_YYY/bt/template_XXX.xml).
  This commit handles the following:
    1. Stop instance with old ERP5 without template_XXX.
    2. Update erp5.git.
    3. Start instance.
    4. Upgrade erp5_property_sheets and erp5_YYY bt5s in *one* transaction from portal_templates UI.
    => When upgrading erp5_YYY, BusinessTemplate.importFile() imports erp5_YYY/bt/*.xml where the
       list of files is based on BusinessTemplate class propertyMap(), but at this point accessors
       have not been re-generated yet, thus template_XXX is not returned by propertyMap() and
       erp5_YYY/bt/template_XXX.xml is not imported.
       => portal_templates/erp5_YYY new BT does not have template_XXX property set at all.

  <family_name>-0..9 when number of nodes <= 10
  <family_name>-01..09 (or n) when number of nodes > 10

In scalability tests instance keeps track of old used nodes and when nodes > 10
will pick by default sort "activity-0" which is NO longer an existing zope process.
This is an ugly fix and real woraround is to have something like activities-000x schema by default

This is the case with runUnitTest wrapper created by SlapOS but is not actually required
as manage_addERP5Site has 'test test' as default value.

This fixes:
  File "custom_zodb.py", line 70, in <module>
    sql_db = Products.ZMySQLDA.db.DB(os.environ['erp5_sql_connection_string'])
  File "UserDict.py", line 40, in __getitem__
    raise KeyError(key)
KeyError: 'erp5_sql_connection_string'

This module is not sorted, we cannot just do assertions based on line
index.
Instead we do two different approaches:
 - When there is only one "empty" draft transaction, we check locate the
line based on the state cell and then check each cell relatively to that
first xpath
 - After we had a second draft, we just check that we have two lines
matching each cell predicate.

Sometimes test fail we don't have any information about what the problem
was.

Using the same technique of turning a promise into "a function called
several times until it returns true or false", we can get rejection
failures in the selenium error message.

The term (used for example on HTTPExchange_view/my_follow_up_title ) is
"Follow-up". This will fix testNamingConventions failure.

so that user can overwrite easier in html

For options:
${WebPage_insertFollowUpCostEffortReport}
${WebPage_insertFollowUpCostEffortDetailReport}
script's name is changed to Base_generateCostEffortReportContent
and parameter is changed also