This is to support SLAPOS-EGG-TEST which runs tests for multiple
repositories from the same test suite. Evaluating each commit from
each repository with the result of the test result is problematic because
every time one test fail, all repositories are marked as failed.

Introduce a new property on test result repository to optionally define
the pattern of test result line to consider for this repository. This way,
with our SLAPOS-EGG-TEST running tests for slapos, slapos.core,
... etc and producing test result line with the same title as the repository
name, we can use something like `slapos$` (the pattern is a regular expression)
to match only slapos,  `slapos\.core` to match only slapos.core etc.

This also allow to define more complex relation if necessary, for example kedifa
and caucase seems related, maybe we want to configure so that a failure on kedifa
test suite marks the commits from both kedifa and caucase as failed (or maybe
not, but at least this way should make it possible)

/reviewed-on nexedi/erp5!964

When a commit is no longer reachable from a branch, gitlab API does not
allow annotating the commit.

This happens quite often when we push force in the branch after test
result started to run on this branch.

/reviewed-on nexedi/erp5!972

The previous way of using portal.ERP5Site_absoluteUrl() +
test_result.getRelativeUrl() could not work with ERP5JS URLs.

To be compatible with this and also maybe erp5_web-style URLs if we want
to link to public tests results, we should have more flexibility in how
we generate URLs.

Introduce a "test result url template" property on gitlab connector, see
unit test for a renderjs ui compatible usage.

/reviewed-on nexedi/erp5!963

Because gitlab way of passing project ID as user/project URL-encoded
does not support dots (it would needs to be encoded as %2E) and that
requests rewrites %2F from URL to . (which is probably correct, that's
the RFC), we cannot use encoded paths for when they contain a dot.

To workaround this, when user or repo as a dot, make another API call to
get the numerical project ID and use that instead.

We only do that for projects with a dot because that's an extra request
we'd like to avoid.

/reviewed-on nexedi/erp5!962

While deploying nexedi/erp5!924 we found out that this script was not working in these cases:

 * when buildout section id contains `-repository` there's a convention that this is stripped and does not appear in test result reference ( implemented [here](https://lab.nexedi.com/nexedi/erp5/blob/31804f683fd36322fb38aeb9654bee70cebe4fdb/erp5/util/testnode/NodeTestSuite.py#L95) )
 * when buildout section id contains `-` this script crash
 * when there's no buildout section id and there's no fix for that, because buildout section id is a required property. If we encounter this failure, we fix the data by putting a buildout section id on test suite repository.

/reviewed-on nexedi/erp5!961

Guarded with Manager role, as they allow exporting entire source files & scripts.

ZODB Components: Make 'Origin' field read-only as this is set during migration and should not be modified later on (cf632afb).

ZODB Components: Revert "Also, allow developer to call validate action from 'modified' state to handle import use case" (part of 1cb2dc4c).

This was badly implemented as it didn't handle the following use cases:
  * {draft,invalidated} => validated.
  * clearRecordedPropertyDict() was not called on re-validate.

For now, re-validate through modifying {text_content,reference,version}.

Until now it was disabled which means that if Component A imports Component B
and the latter is not in {validated,modified} state, Component A could be
validated without raising any error and failed at execution time.

As this relies on Pylint transform/hook and avoiding monkey patch as much
as possible, make Products.ERP5Type.patches.pylint available for Python3 (not
actually tested with ERP5 but no AttributeError nor ImportError with Python3
with this code).

Also, allow developer to call validate action from 'modified' state to handle
import use case:
  1. Edit A which raises an error stating that B.
  2. Fix B and validate it.
  3. Validate again A without requiring a modification of {reference,version,text_content}.

ZODB Components: Source code was checked even when setting text_content_{error,warning}_message_list properties.

So only check source code and validate when _set{TextContent,Reference,Version}
are called and remove wildcards.

Because this is using SQLDict, when we had multiple conversion
activities for the same path with different conversion parameters, only
one was executed.

We don't want this here, as the recent failures on
testDmsWithPreConversion.TestDocumentWithPreConversion are showing, when
the same image is referenced with different conversion parameters we
want to pre-convert for all conversion parameters.

Use SQLQueue, which allows calling the same method more than once.

/reviewed-on !971

Sometimes validator.erp5.net replies with error code 502 and this cause
ERP5 tests to fail. While this is a bit like ignoring problems, problems
with validator.erp5.net should not impact ERP5 tests results.

/reviewed-on !968

This is a fixup for commit 1519d81a.

There was a typo.

This test was using a blind `pause` instead of an explicit waitFor*, so
it was failing when machine was not fast enough.

Also refactor the test a bit to simplify the assertion by first
selecting the iframe we are going to inspect and make the test
compatible with both chrome and firefox - they behave differently when
interpreting new lines in selenium test tables.

/reviewed-on !967

We want to have FAILED test results before PASSED, to easily see the
failed tests.

Apparently this was a local change on nexedi ERP5 for some time but the
change got lost in last update. Let's commit it to make this
permanent.

/reviewed-on !960

test_04c_startTestSuiteOrderWithManyTestNodes is using same test results
names ("test suite 1", "test suite 2", ...) as some previous tests (
test_04b_startTestSuiteOrder ) so it's safer to start the test by
cancelling all previous test runs and renaming them.

/reviewed-on !959

erp5_trade_ja: New bt5 for wkhtmltopdf printout for 'Sale Invoice' with >2019/10/01 new Japanese VAT ratio support.

Based on the following ODT Templates (erp5_invoicing):
  * Invoice_viewAsODT.oot.
  * Invoice_viewAsODTStyles_l10n_ja.oot.

wkhtmltopdf template is based on work from slapos_accounting bt5:
  * SaleInvoiceTransaction_viewSlapOSPrintout.zpt.
  * SaleInvoiceTransaction_getSlapOSPrintout.css.zpt.

Conversion Server code is no longer bound to OOo, as emphasized by:
  * Renaming of Preference Properties ooodoc_server* to document_conversion_server*.
  * Conversion Server exceptions are already defined in Document.py.
  * Conversion Server also handles video/audio/... conversions.

Thus, refactor the code to connect to Conversion Server by moving it from
Products.ERP5OOo.Document to Products.ERP5.Document.Document (while keeping
backward compatibility):
  * Renamed:
    + OOoServerProxy => DocumentConversionServerProxy
    + OOO_SERVER_PROXY_TIMEOUT => DOCUMENT_CONVERSION_SERVER_PROXY_TIMEOUT
    + OOO_SERVER_RETRY => DOCUMENT_CONVERSION_SERVER_RETRY
  * Moved:
    + enc
    + dec
    + global_server_proxy_uri_failure_time

Also, Introduced erp5.module.TransformLib (in erp5_core as currently all Transforms
are there even though it should probably not be so) to define DocumentConversionServerTransform
and which will hold libtransforms content when this will be moved to ZODB Components.

Note: Ideally, OOOdCommandTransform should inherit from DocumentConversionServerTransform
but wkhtmltopdf Handler on Cloudooo side is a hack only implemented in Manager.convertFile()
whereas OOOdCommandTransform still uses legacy Manager.run_generate(), so leave it as it is
to avoid breaking things (this will be addressed in a separate MR).

/reviewed-on !955

/reviewed-on !965

ZODB Components: Add 'Origin' (source_reference) field showing from which FS module it was imported.

* pylint may return a false positive error which have to be disabled and
  failing to import it because of that requires to edit on the FS and try
  again so it is not practical for a whole Product. Instead it is easier
  to import it and not validate
* Validation was done only for 'Test Component' and 'Extension Component',
  but all imported Components had their consistency and source code checked
  and this is not consistent to not validate but do these checks.
* importFromFilesystem() was checking consistency and source code, and this
  was done again when validating.

So leave the imported ZODB Components as draft and let the developer fixes
issues upon validation before committing.