Jérome: slightly adjusted manually to just use range where it does not
make a significant difference (for example in test)

also str representation of unicode character is different.

Co-authored-by: Carlos Ramos Carreño <carlos.ramos@nexedi.com>
Co-authored-by: Emmeline Vouriot <emmeline.vouriot@nexedi.com>
Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>

some conversion (TextDocument) depend on the content type, so it's
necessary to first update the content type before trying to convert to
base format

group_id is used as key of OOBtree and as documented, it's not
possible to mix keys that can not be compared, so we can not have a mix
of string and bytes. Since years

 - Products.PythonScripts now has a __loader__
 - do not use < > as filename for component on py3, this makes linecache
 work out of the box. On py2 I think it was causing errors trying to
 actually open the file, but this does not seem needed on py3 and
 simplifies everything

new test with ERP5-style workflow to cover python3 migration

with ROUND_DOWN, we have a different behaviour between py2/py3, that caused failures in
erp5_simplified_invoicing:testTradeModelLine.

Here is what happened in _round(1.9999999999999998) in
bt5/erp5_simulation/DocumentTemplateItem/portal_components/document.erp5.FloatEquivalenceTester.py

* py2
decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN')
=> Decimal('2.000000')
(because str(1.9999999999999998) is '2.0')

* py3
decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN')
=> Decimal('1.999999')
(because str(1.9999999999999998) is '1.9999999999999998')

But ROUND_DOWN result of 1.9999999999999998 with 0.000001 precision should be 1.999999 thus py2 behaviour is wrong.

Run zope with ERP5_COMPONENT_OVERRIDE_PATH set to a : separated list of
path containing components files to load components from files instead
of portal_components.

This can be used to repair zope after a bad edit of component.

for pylint 3 to understand erp5 dynamic modules

We want these columns to be "binary" so that mariadbd compares them
without any collation, but we don't want to use binary type, because on
python 3 the brain attributes are bytes (user ids are strings everywhere
else).

This also normalize the same columns present in worklist cache table.

I don't know a PYTHONHASHSEED to see the problem on python2, but on
python 3 erp5_payroll_l10n_fr:testSimplifiedPayslipReport fails all the
time with this.

On python3 the percentages are sometimes printed as 6.8500000000000005%

cookie crumbler uses username:password base64 encoded and this relies
on extracting the username from the cookie to set the session, but
other authentication methods do not embed the username, but still share
the same scripts to set the authentication cookie (so that we have one
central point setting cookie with all the necessary attributes for
security).
The problem is that it's incorrect to try to decode an username with
cookies from other authentication methods, simply because they do not
contain the username. On python2 this was not causing visible error
because everything is str, but the decoding error on python3 revealed
this.

in Python 2, _aq_dynamic() returns None without try..except but it raises ValueError in Python 3.

(python 2)
> /SR/parts/erp5/product/ZSQLCatalog/Extensions/zsqlbrain.py(31)_aq_dynamic()
 31  ->   def _aq_dynamic(self, name):
 32         """Acquire an attribute from a real object.
 33         """
 34         if name.startswith('__') :
 35           return None
 36         return getattr(self.getObject(), name, None)
((Pdb)) getattr(self.getObject(), name, None)
*** ValueError: Unable to getObject from ZSQLBrain if ZSQL Method does not retrieve the `path` column from catalog table.
((Pdb)) r
--Return--
> /SR/parts/erp5/product/ZSQLCatalog/Extensions/zsqlbrain.py(36)_aq_dynamic()->None # <-- !!!
Co-authored-by: Jérome Perrin <jerome@nexedi.com>