This reverts commit 82595cd8.

This supports both python2 and python3. For python3, this decode() properly
arguments returned by string_literal() to have str(), otherwise the query string
is an str() (DocumentTemplate) and the arguments are bytes().

In other places, bytes() is used directly but in this case this is not needed
and would require monkey patching (at least) DocumentTemplate.

And _mysql/mysqldb API (_mysql.connection.query()) converts the query string to
bytes() (additionally, cursor.execute(QUERY, ARGS) calls query() after
converting everything to bytes() too).

TODO: Instead of doing this ourself, should we use cursor.execute(QUERY, ARGS)
      which does conversion to bytes()? Performances?

{encode,decode}string() aliases available but clearer this way...

And Zope now mandates it to be a string ({Shared.DC.ZRDB.TM.TM, ITransactionManager}.sortKey()).

When rendering a proxy field, 3 different fields can come in play:
1. the field to be rendered
3. the template field (i.e. not a proxy field) that knows how to render
2. possibly an intermediate proxy field that contains the value to render

What's difficult when rendering a proxy field is to take the above 3 fields
into account and this commit does it by creating a temporary field:
1. 'field' variable in TALES
2. the value
3. the code

Before this commit, 1 could be wrong.

This was deprectated because we don't have get*ById for other modules
and tools, we just use OFS API. This should also be slightly faster
because one less method call (and one less call to warning)

exiting the context manager restores the original DateTime behavior

This tests the test framework, because this code is tricky.

I'm not sure if this is used, but not being valid python code cause
problems with code analysis tools

mock has several advantages, the main one here is that it errors when
patching does not replace an existing attribute, which happens when we
are not patching the right place.

These attributes are not the same place in DateTime 2 and 3, this code
when using DateTime 2 was replacing the attributes, but in DateTime 3 it
was just creating new attributes that were never used. Update the code
to patch the DateTime 3 location

Maybe this made sense long time ago, but nowadays we are using
equivalence testers which tolerate date differences with more flexibility.

createDateTimeFromMillis was also problematic as it uses internal
private attributes of DateTime which is a pylint error with more recent
DateTime

Error `Using import with a level specification isn't supported by AccessControl: AccessControl`:
    eggs/Zope-4.5.3+slapospatched002-py3.7.egg/Products/PageTemplates/Expressions.py(188)_eval()
  -> ob = self._subexprs[-1](econtext)
    eggs/zope.tales-5.1-py3.7.egg/zope/tales/expressions.py(153)_eval()
  -> ob = self._traverser(ob, element, econtext)
    eggs/Zope-4.5.3+slapospatched002-py3.7.egg/Products/PageTemplates/Expressions.py(84)boboAwareZopeTraverse()
  -> request=request)
    eggs/zope.traversing-4.4.1-py3.7.egg/zope/traversing/adapters.py(156)traversePathElement()
  -> return traversable.traverse(nm, further_path)
    eggs/zope.traversing-4.4.1-py3.7.egg/zope/traversing/adapters.py(58)traverse()
  -> return subject[name]
    eggs/Zope-4.5.3+slapospatched002-py3.7.egg/Products/PageTemplates/ZRPythonExpr.py(56)__getitem__()
  -> mod = safe_builtins['__import__'](module)
    parts/erp5/product/ERP5Type/patches/Restricted.py(451)guarded_import()
  -> return orig_guarded_import(mname, globals, locals, fromlist, level)
    eggs/AccessControl-4.2-py3.7-linux-x86_64.egg/AccessControl/ZopeGuards.py(410)guarded_import()
  -> "supported by AccessControl: %s" % mname)

Permissions are managed by the document_publication_worflow