Avoid iterating over all columns known to catalog to then restrict to a
single table by using SQLCatalog API.
Only check for one range column suffix as code anyway relies on the triplet
of columns to be consistently present. Document this in the code and get
rid of now-unneeded range_column_set mechanism.

str.encode() first performs an implicit conversion to unicode using
sys.getdefaultencoding(), which is usually 'ascii'. The 'isort' module
changes the default encoding to utf-8, leading to UnicodeEncodeError
instead of UnicodeDecodeError. Let's simplify all this.

These methods will be used in erp5 catalog view in restricted environment.
Loosen the security on methods which we will use in erp5 catalog view in
restricted environment.

Required as preparation for migrating to ERP5 catalog which itself has an accessor
`isIndexable` which we plan to remain disabled all the time. So better to rely
directly on isIndexable from erp5 site object.

This would also remove the need of evaluating the globals every time.

/reviewed-on nexedi/erp5!314

/reviewed-on !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 nexedi/erp5!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.