correct case is *validated*

- get tools from portal, not context, to prevent slow acquisition
- stop using abbreviated names (ctool, stool etc)

This is not public API and is not supposed to be used outside of catalog
tool.

Using getObject here is also wrong because it does not apply security
and does not check provided argument type.

To prevent retrieving too many documents, we usually pass limit=2 for
safety.

To detect inconsistencies, when only one result is expected we rely on
`brain, = portal_catalog(limit=2)` style unpacking to fail if more than
one result were found.

This was an error reported by pylint. This changes fixes the behavior, but should have been the original behavior;

to InternalInvoiceTransaction_getAuthenticatedUserSection.

It was a violation of our naming conventions.

This was a violation to our naming conventions

/reviewed-on nexedi/erp5!313

Revert "erp5_officejs_afs_directory: add missing allow cross domain header"
This reverts commit 2674afaa.

Revert "erp5_officejs_afs_directory: rewrite custom storages and automate openhub data retrieval via proxy"
This reverts commit f74f420e.

Such default parameters prevent even entering the module once the document
count is large enough.

Do log it, but do not let it propagate.

Since early days of @arnau work on ERP5 components, we have pylint integrated as a way to check the code in components and in python scripts but nothing prevents us from commiting code with lint errors, leaving the problem for the next developer. 

For this, I extended [`CodingStyleTestCase`](https://lab.nexedi.com/nexedi/erp5/blob/88e4b34ff67aa07447f81c8af836feba607843e8/product/ERP5Type/tests/CodingStyleTestCase.py) that was introduced for very similar purpose so that it also  use our tool to check python code. This way,  we can have failing tests when the code do not pass pylint.

What's still not good is that if we want a business template to be tested, we have to explicitly add a test for this business template, but it's also the case for all our "static" tests (naming conventions, HTML validation etc).


A missing feature was that there was no way to get an overview of all the reported problems on a business template. For this, I added a report action on business template that uses the same code to display errors in all *python* code from a business template:

![ERP5_pylint_business_template](/uploads/13613199227884f0340b8f1c40ca4418/ERP5_pylint_business_template.png)
( the lines have direct links to edit python code )

Because `testERP5WebCodingStyle` was already here checking `erp5_web` (well not really because it was no longer using `CodingStyleTestCase` correctly) , I fixed all problems reported by pylint in erp5_web. In reality it only took a few minutes to do this.

PS: I don't know exactly how we could integrate javascript linter in all this. We have a [`test_javascript_lint`](https://lab.nexedi.com/nexedi/erp5/blob/master/product/ERP5/tests/testXHTML.py#L171), but it does not test much of the code written recently because it only checks portal skins. @romain and @vincentB maybe have plans for this. Anyway, it's out of the scope of this.

/cc @kazuhiko @vpelletier @tc 

/reviewed-on !308

erp5_mysql_innodb_catalog: add safety LIMIT in z_getitem_by_path and z_getitem_by_uid to avoid fetching all rows in case of empty argument.

otherwise Localizer will not work in grouped activity.

business template metadata was not commited

This replaces ERP5Site_checkPythonScriptsWithPyflakes that I guess
nobody was using

CodingStyleTestCase tests by default the last business template returned
in getBusinessTemplateList, but  getBusinessTemplateList returned value
changed overtime and this test did not really test erp5_web

Also name include "ERP5 Web" in test class name, as it tests ERP5 Web.