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.

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.

See merge request !1085

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

Related to 58c9f7c3 in slapos.git.

In nexedi/erp5@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

It was required by Handlebars

Allow to use it from erp5_xhtml_style.

This business template is not used and contain a preference referencing
non existing paths, which causes errors in coding style test with
test_moduleListMethod that cannot display accounting module, because
preference is set to group/my_group which does not exist.

Instead of trying to fix, let's remove the business template if it's not
used.

Project_viewAccountingTransactionList uses some scripts from
erp5_accounting

metadata was not committed, so next time VCS tab is used on this
business template the path is marked as removed.

authentication policy, invoicing, ingestion and credential

See merge request !1081

When these printouts were made, cloudooo did not had so many fonts as
today, and it was picking up "Liberation Sans" for the "Arial" used in
these templates;

Since
nexedi/slapos@135cbe43
( yes, 5 years ago ) we have more fonts, and since then the rendering of
these printout changed, a "Roman" font was selected instead.

This changes the templates to use explicitly "Liberation Sans", which
makes the printouts use the old looks even on newer cloudooo .

See merge request !1080

In case of erp5_core business template update this code is called (with update=True argument)
and thus it will effectively override previous portal_alarms' state which
is wrong as no "general purpose" code should overwrite potential
developer configuration.
Tests passing at https://nexedi.erp5.net/test_result_module/20200324-3BC4D696 thus merging right away.

See merge request !1086

See merge request !1050

business template update this code is called (with update=True argument)
and thus it will effectivly override previous portal_alarms' state which
is wrong as no "general purpose" code should ovewrite potential
developer configuration.

Also extend coding style test to cover this kind of issues with business templates.

See merge request !1083

This caused upgrader errors such as:

    Error: Web Site web_site_module/ooffice_spreadsheet references a non existant appcache gadget_officejs_spreadsheet.appcache

This caused upgrader errors such as:

    Error: Web Site web_site_module/officejs_smart_assistant references a non existant appcache gadget_officejs_spreadsheet.appcache

We want to detect business templates with problems that would prevent to
run upgrader.

Mimic xhtml style.

Deleted Device Document as it is not used anywhere and not really useful:
Item can be used instead.

Migrated SubscriptionItem from FS to erp5_open_trade: this is the contract as
in https://www.erp5.com/erp5-TechnicalNote.Open.Order#contract and make
erp5_payroll depends on erp5_open_trade as Employment Contract is a
SubscriptionItem and, per design, Payroll is kind of an Open Order.

ERP5TypeInformation are used for Portal Types of Portal Types and needed to generate at
least Workflow Methods early at Zope startup (initializePortalTypeDynamicWorkflowMethods()
and portal_type_group_filter in the problem reported on MR 1032) for very basic Portal
Type classes (such as Category Tool). So, Leave these on the filesystem for now, we can
eventually deal with them later if necessary.