Commit c663257f (Commit fix done by Julien and Leonardo) added network
barrier into ZODB.Connection.newTransaction to fix issues when
activity node A1 was woken up by message from another activity node A2
through SQL, but A1's ZODB view was not yet updated with changes
committed by A2.

That fix prepended `ping` call before original newTransaction actions,
but instead of tailing to original ZODB newTransaction after the ping,
it copied newTransaction code from ZODB.

Today this can cause the following problems:

1) the code that was copied is valid only for ZODB3 and ZODB4, but is not
   valid for ZODB5 as that place was changed by upstream:

   https://github.com/zopefoundation/ZODB/blob/5.5.1-56-gbb9bf5393/src/ZODB/Connection.py#L734-L742

2) wendelin.core 2 relies on patching ZODB.Connection.newTransaction
   further to install "Connection.onResyncCallback" functionality to
   keep ZODB and WCFS connections in sync:

   https://lab.nexedi.com/kirr/wendelin.core/blob/25c3184d/lib/zodb.py#L264-291

   So if ERP5Type.patches is imported after wendelin.lib.zodb, the
   functionality installed by wendelin.core will be lost.

-> Fix both issues by avoiding code duplication and just tailing to
original ZODB newTransaction after the ping.

/cc @seb, @jm, @vpelletier, @romain

This moves portal_solver_processes from erp5_base to erp5_simulation as its
Portal Type definition is already there and it was initially moved away from
erp5_simulation presumably because erp5_simulation was for new Simulation at
that time.

Also, as delivery_causality_workflow uses portal_solver_processes, move it to
erp5_simulation (along with delivery_causality_interaction). This required
fixing Unit Tests to install erp5_simulation before erp5_trade (it already
depended on it anyway).

When migrating `Immobilisation` Document, imports of not yet migrated
ImmobilisationMovement Document were also replaced...

testUpgradeInstanceWithOldDataFs: Check that all Portal Types classes can be loaded successfully after running upgrader.

testUpgradeInstanceWithOldDataFs: Old Data.fs was created with `--portal_id=erp5`, so it should be passed for erp5testnode too.

ZODB Components: Migration dialog: Only consider Portal Type Document/Tool class and not all its subclasses.

This makes it easier to migrate only Document/Tool classes to the current bt5,
considering that subclasses below are likely to be used in several places.

These conditions were added many years ago and they should not be needed
since checkboxes work without this extra complexity

Move `BusinessTemplate_getPythonSourceCodeMessageList` to `erp5_core`, so that coding style tests don't need to install `erp5_administration` and all its dependencies.

`erp5_core` is not the final place for this, because this is not required to for business template bootstrap, but this is temporary until we finish business template reorganisation.

This revealed several problems of wrong dependencies between business templates that we could not see before, when coding style was installing too many business templates such as `erp5_pdm`, `erp5_trade`, `erp5_simulation`, `erp5_project`.

See merge request !1089

ZODB Components: Interface Component: pylint was incorrectly emitting: `W: __init__ method from base class is not called`.

now BusinessTemplate_getPythonSourceCodeMessageList is in erp5_core

ZODB Components: Ignore low-level TypeProvider (TypesTool and SolverTool) classes in FS migration Dialog.

This is a script from erp5_core, but Inventory Module is a portal type
from erp5_trade.

Component is not a valid prefix for python components from
portal_components, it's the name of a resource class from erp5_pdm.
ComponentMixin is the valid prefix.

This scripts are used only in code mirror integration

This busines template has actions using forms from erp5_simulation, for
example Rule_view on Payment Simulation Rule

This portal type is defined in erp5_trade, and the allowed content type in
Delivery Builder is defined in erp5_trade, only the allowed content type we
defined in erp5_base, which is incorrect, because it makes erp5_trade
allow some non existing types in Order Builder.

Fix this by moving the allowed content type in erp5_trade.

- fix indentation
- make overloaded methods accept same arguments as on parent class
- use list comprehension instead of map()

PDM has some scripts, such as Consumption_asCellRange, it seems
consumption is a generic concept that should be in pdm, not in apparel.

erp5_pdm does not depend on erp5_trade, so it cannot use proxy fields
from erp5_trade

This business template uses proxy fields from erp5_trade

These scripts are used in coding style tests, but because it was in
erp5_administration, all coding style tests had to install
erp5_administration and all its dependencies. Which is against one idea
of the coding style test, which is supposed to check that business
templates declare their dependencies correctly, but if we install all
business templates that erp5_administration depends on, the test might
have false positives of missing dependencies.

Since 7b4a3d4c instead of subscribing after add code unsubscribed which is illogical. Revert back. Credit Kaz.

Tests passing : https://nexedi.erp5.net/test_result_module/20200327-660269E/view?ignore_layout:int=1

See merge request !1092

This is already defined in erp5_simulation, also Solver Type does not
exist in erp5_base

testUpgradeInstanceWithOldDataFs: New Unit Test to check upgrade of old instance to current ERP5 version.

After copying old instance ZODB and SQL from erp5-bin.git, this checks whether
instance can be successfully through upgrader. Introduced because of 140be41d.

Since 7b4a3d4c instead of subscribing after add code unsubscribed which is illogical. Revert back. Credit Kaz.

See merge request !1085

runUnitTest: Set `skip-ownership-checking true` as we already do for a normal instance through zope.conf.

Related to 58c9f7c3c688854958592590dd396929b5a0c8d4 in slapos.git.

In 935b39f9 we accidentally enabled coding style test for `erp5_project`. Let's fix the current problems reported by coding style test.

See merge request !1087

See merge request !1079