Do not access form submission REQUEST from the listbox list method,
as it is rendered asynchronously in ERP5JS

This reverts commit 35b2c024.

Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

erp5_web_renderjs_ui: keep previous focus color

This reverts commit a87db49b.

Change max age to 1 hour and 1 day

Most listbox functionnalities are not supported by web_js_style for now, as no form is used by default

Their contents is already provided by the HTML page template.

Generate a hfeed in the HTML rendering.
https://indieweb.org/feed

Provide a RSS feed automatically.

Only generate the feed when rendering the web section in view mode.

Extract all feed informations in Javascript to allow styling it as a blog.

See merge request nexedi/erp5!1486

See merge request nexedi/erp5!1498

Double translation happened when:

- For sql_catalog.isValidColumn(name)
- When search_columns is empty
- When selection_sort_order and sort_columns are empty

So delaying translation on column titles until *_column_list are finalised.

Before this fix, double translation on Sale Order title was happened every time
displaying a Sale Order Line, for example.

Category spreadsheet import did not delete categories if some documents
where related to these categories. While this may make sense when using
this import in site with already some data, in many cases, we want to
be able to delete the categories, so that the result is that the category
tree match the imported spreadsheet.

This extend the dialog to support a new "force delete" mode that delete
categories even if they are use, leaving the documents using categories
with broken relations.

Spotted when comparing this code with ZPublisher.Publish.

Once a response has been written to, the status and headers are supposed
to have been sent over the network. So any future change to them is moot.
Likewise, setBody does nothing: only write can continue appending to the
existing body.
As in the case of WSGI the response does not actually get sent just yet:
- lock the body
- store finalize() result
Also, make the order in which body and stdout are returned consistent with
HTTPResponse: body is returned first (as part of HTTPResponse.write's call
to self.outputBody, which calls self.__str__, which emits body), and then
stdout content.
Also, add support for cases whre the existing body is a file or an
IUnboundStreamIterator.

err_hook may re-raise when it is specifically told not to render an error
page. Such exception does not mean err_hook failed, so it should not be
re-raised by WSGIPublisher: re-raising in WSGIPublisher means handing the
exception over to waitress, which will have no other choice than producing a
generic error page that we have no control over.

Transaction must be aborted even if the state is getting so bad that the
exception is being re-raised. Leaving an open-ended transaction is never
acceptable.

MariaDB seems to be using inconsistent lock acquisition order when
executing the activity reservation queries. As a consequence, it produces
internal deadlocks, which it detects. Upon detection, it kills one of the
involved query, which causes message reservation to fail, despite the
presence of executable activities.
To avoid depending on MariaDB internal lock acquisition order, acquire an
explicit table-scoped lock before running the activity reservation queries.

On an otherwise-idle 31 processing node cluster with the following
activities spawned, designed to stress activity reservation queries
(many ultra-short activities being executed one at a time):
  active_getTitle = context.getPortalObject().portal_catalog.activate(
    activity='SQLQueue',
    priority=5,
    tag='foo',
  ).getTitle
  for _ in xrange(40000):
    active_getTitle()
the results are:
- a 26% shorter activity execution time: from 206s with the original code
  to 152s
- a 100% reduction in reported deadlocks from 300 with the original code
  to 0

There is room for further improvements at a later time:
- tweaking the amount of time spent waiting for this new lock to be
  available, set for now at 1s.
- possibly bypassing this lock altogether when there are too few processing
  nodes simultaneously enabled, or even in an adaptive reaction to
  deadlock errors actually happening.
- cover more write accesses to these tables with the same lock

From a production environment, it appears that the getReservedMessageList
method alone is involved in 95% of these deadlocks, so for now this change
only targets this method.

testRestrictedPythonSecurity imports *_black_list variables.