* Review SMS sending API to move the complexity and the various parameters from the interface script `ShortMessage_send` to the gateway interfaces.
 * Fix problem with mobyt with messages longer than 140 characters
 * Fix [#20170709-17309B6](https://nexedi.erp5.net/bug_module/20170709-17309B6)
 * add an (incomplete) test


/reviewed-on nexedi/erp5!580

![image](/uploads/f86e89066db17979735f892c5c36a90f/image.png)


This introduces a new portal type group "payment request"

/reviewed-on nexedi/erp5!831

This fixes the issue that a transaction with many big messages failed to
commit. By dynamically find the maximum allowed size of a query, it also
speeds up insertion by minimizing the number of queries.

e84d2b51 introduced template_{interface,mixin}_id BusinessTemplate properties
in erp5_property_sheets without keeping backward compatibility and thus
preventing update:
  Module Products.ERP5.Tool.TemplateTool, line 1446, in upgradeSite
    update_catalog=update_catalog)
  Module Products.ERP5.Tool.TemplateTool, line 1289, in updateBusinessTemplateFromUrl
    imported_bt5 = self.download(url = download_url, id = id)
  Module Products.ERP5.Tool.TemplateTool, line 382, in download
    bt = self._download_local(path, id)
  Module Products.ERP5.Tool.TemplateTool, line 328, in _download_local
    bt.importFile(path)
  Module Products.ERP5.Document.BusinessTemplate, line 5887, in importFile
    self.storeTemplateItemData()
  Module Products.ERP5.Document.BusinessTemplate, line 5165, in storeTemplateItemData
    InterfaceTemplateItem(self.getTemplateInterfaceIdList())
AttributeError: getTemplateInterfaceIdList

ZODB Components: Likewise Document, add Mixin (erp5.component.mixin) and Interface (erp5.component.interface).

* One Mixin/Interface class per ZODB Component.
  => Already the case for FS Mixin, not for Interfaces.
* ZODB Components module name ('reference' property) and class name:
  + Mixin: FooMixin.
  + Interface: IFoo.

Rationale:
  + Avoid current FS hacks: registry (Mixins, mixin_class_registry) or import
    all classes explicitly in __init__.py (Products.ERP5Type.interfaces).
  + Consistent naming.
  + Consistent with ZODB Documents Components.

Also, modify pylint checker to handle Zope Interfaces:
  + E: 4, 0: Inheriting 'Interface', which is not a class. (inherit-non-class)
  + E: 5, 2: Method has no argument (no-method-argument)

Follow nexedi/erp5@1664e541

It seems developpers didn't update their instances.

The fields are displayed only if some portal types are configured as
member of payment_request group. This means that currently it's not
displayed by default.

This moves the remaining DTML queries to Python, dropping the 'activity' skin.

Dealing with conflicts of uids is easier if the inserted uids are consecutive:
now, only 1 random value is generated, as base uid. This also preserves the
order of insertion, which is wanted for performance reasons:
- No more random write in the primary index.
- When modifying several lines of several documents, 1 document being processed
  at a time, we'd like that any grouped activity (usually indexation) follows
  the same order, so that a processing node prefer many lines from a few
  documents instead of mixing lines from too many documents at the same time.
  This is usually better for caches.

Average age of activities is dropped because it would become
too complicated to implement and it's useless information.

The original goal was to improve performance by removing the
`processing_node_processing` index and the queries that modified
these 2 useless columns.

The root call to getExecutableMessageList (i.e. the one from distribute)
is fast enough and won't hold old revisions of the database for too long.
It is also completely read-only so it won't lock anything.

This caused useless communication with the server.

As shown in the following example, on a big catalog table,
MariaDB is able to use several indices at the same time
('...' are obfuscated unique values):

  > analyze select SQL_NO_CACHE uid, relative_url from catalog where reference='...' OR relative_url='...';
  +------+-------------+---------+-------------+------------------------+------------------------+---------+------+------+--------+----------+------------+--------------------------------------------------+
  | id   | select_type | table   | type        | possible_keys          | key                    | key_len | ref  | rows | r_rows | filtered | r_filtered | Extra                                            |
  +------+-------------+---------+-------------+------------------------+------------------------+---------+------+------+--------+----------+------------+--------------------------------------------------+
  |    1 | SIMPLE      | catalog | index_merge | Reference,relative_url | Reference,relative_url | 768,767 | NULL |    2 |   2.00 |   100.00 |     100.00 | Using union(Reference,relative_url); Using where |
  +------+-------------+---------+-------------+------------------------+------------------------+---------+------+------+--------+----------+------------+--------------------------------------------------+
  1 row in set (0.00 sec)

So mixing different dependency types with OR should be fine
(no need to split into more subqueries and join with UNION).

Creating a Software Publication doesn't require to change the Software Product.

And so, simplify the code logic, as product is always created before the publication

Do not wait too long when pushing a new application.

Do not modify document history if nothing changed

Set the wildcard URL on a system preference.

Those web site do not work in offline mode, so client must revalidate the components.

Update appcache

Drop unused scripts

Thanks to Vincent Bechu for his work on this commit.

As noted in a comment in this BT's Base_redirect implementation, original code
does raise when abort_transaction is true.
Not raising in this implementation means that this script will return to caller,
while it never does on original code.
Also, to add insult to injury, this utterly bogus implementation interferes with
transaction boundaries. So suddenly, a single publication spans over 2
transactions, which can lead to:
- ZODB Connection sharing, breaking transaction isolation
- the second transaction implicitly created by this abort (actually, by the next
transactional connector registration to transaction) may be committed,
in which case anything done after Base_redirect returns will be
persistently committed, against caller's explicitly specified intent, and against
all developer expectations.

NEVER TOUCH TRANSACTION ! Only CMFActivity and unittests are allowed
this level of access (and CMFActivity should be modified out of this exceptional
state).

Linshare Use the same configuration than ERP5

Thanks to Vincent Bechu for his work on this topic.