Implementation dependant parameters, such as message type or quality,
must be defined by the gateway class, not in the common
ShortMessage_send script.

This should make it easier to switch implementations.

Also:
 * send method is expected to be called once per recipient. I guess we
   prefer to isolate messages than to batch send messages efficiently.
 * send method expect relative url of sender and reciever documents, so
   that it can decide which properties to use.
 * drop `sender_title` parameter, now the gateway implementation decide
   what to use.
 * drop `test` parameter. For simulation mode, set simulation mode on
   the gateway instance
 * sms.send() no longer accept direct from_url / to_url / body message.
   It only supports sending what's defined on document properties.
 * SMSTool_afterSend will be called with message_id parameter, not
   message_id_list
 * Split interfaces in two SMS Sending / SMS Receiving.

This is probably incorrect. I believe ERP5ShortMessage's message_type
handling has to be refactored. I guess this should not be part of the
send API but be a property set on the gateway instance in portal_sms

Only mobyt support this parameter, so this break the compatibility with
essendex

this way after a zelenium tests ERP5Site_setupDummyMailHost this will
also reset the mails that could have been sent in previous tests.

This sends too many emails.

Some parts were outdated

The main purpose of these changes is to activate call to portal_sms.send; This way it is isolated it in a transaction that is less likely to fail. Activate with max_retry=0 and conflict_retry=False not to send activity twice in case of error.

There are other cleanups, see individuals commits.

/cc @seb @kazuhiko @gabriel 

/reviewed-on nexedi/erp5!49

Since sending email will not work without destination email, we can globally set this constaint

This way it is isolated it in a transaction that is less likely to fail. Activate with max_retry=0 and conflict_retry=False not to send activity twice in case of error.
As with email, if there was an error in activity processing, it is advised to investigate the transport logs to see if message was send or not.

event_simulation_workflow already call `send` type based method upon start transitions.
This workflow was not chained to portal_type, but if it would have been then message would be sent twice.

It allows to not cancel the loading of the iframe and to prepare the appcache.
The former behavior removed the iframe thus interrupting the preparation of
the appcache.

Putting field in center increases the string field size for ERP5JS

re-apply 25cd1201 that was mistakenly reverted by b847b45e

Hey @Nicolas can you please take a look at all this ?

All this started when I realised we probably do not want to allow grouping reference to be set when we have transactions from different ledgers ( edda8b58 ) and then realized it would be required to allow choosing ledger in grouping fast input instead of just showing all ledgers together ( d1ecbe29 ).

The rest are small changes to move out complex logic from TALES to a script and small fixups.

Thanks

/reviewed-on nexedi/erp5!170

This reverts commit b847b45e, reversing
changes made to 9075a38f.
The reverted commmit has been done automatically, investigation is needed

Putting field in center increases the string field size for ERP5JS

We were just testing that grouping references are automatically set. It
is better to also check they are set to the same thing.

Over the years, we included almost all possible default group by criterions for getMovementHistoryList, so that in essence, we do not group ... for example, we did 7814c521 . It would be better for performance and more logical to just not group by at all, getMovementHistoryList should just return the list of movements.

This is still possible to use explicit group by parameters in getMovementHistoryList, for example grouping by [explanation_uid](https://lab.nexedi.com/nexedi/erp5/blob/c413d34b9d5db0beda2b9540d563529082855d91/product/ERP5/tests/testInventoryAPI.py#L2416) like we can do in [some accounting reports](https://lab.nexedi.com/nexedi/erp5/blob/c413d34b9d5db0beda2b9540d563529082855d91/bt5/erp5_accounting/SkinTemplateItem/portal_skins/erp5_accounting/AccountModule_getGeneralLedgerReportSectionList.py#L111).

I don't have a proper benchmark, but on the instance where we discover the issue, a simple getMovementHistoryList yieliding 112301 results went from several minutes spent in state *Removing duplicates*  (I killed the query after some time) to about 3 seconds.

cc @vpelletier @jm @gabriel 

/reviewed-on nexedi/erp5!171