These methods were generated when rendering the ListBox and with the id
of the ListBox in their name. However, a customer reported the following
problem on Accounting Periods ListBox:

  1. Display Accounting Period ListBox on ZEO-1.
       => The ListBox will be rendered and 'listbox_period_list_*' methods will be generated on ZEO-1.
  2.  Click on 'Next Page' button and the user is redirect to ZEO-2 where the ListBox has never been generated.
       => The method does not exist yet and thus a 404 error is raised.

Instead of having one method per ListBox ID, only one is now created (eg
listbox_setPage() for SelectionTool.setPage()) at Zope startup and the
ListBox ID previously defined in the method name is now defined in the
value attributes of the buttons.

Pattern: SIT_1 => RSPL => SIT_1.

Also, this reduces the complexity by not checking objects twice.

Functional Tests: Migration to PDF.js in recent Firefox clears preference to save automatically PDF files to the disk.

- <a href="c"> was not transformed to absolute url
- split the WebPage_exportAsSingleFile and WebPage_extractReferredObjectDict
into two scripts to allow to evaluate string html data.
+ tests

/reviewed-on nexedi/erp5!180

/reviewed-on nexedi/erp5!167

If we don't propagate movement_list_mode to catalog, this prevents
catalog from raising an error about this unknown parameter.

It's better to create new objects using same script rather than
keeping 2 scripts that try to do the same thing: Folder_create
(script used to add in case we create new object using the icon next to actions bar)
did not support the getRedirectParameter API. We now do all the work
related to adding new object in Folder_create itself.


Test Result : https://nexedi.erp5.net/test_result_module/20161006-39C681E1
Reviewed by: @jm 

/reviewed-on nexedi/erp5!177

This is for backward compatibility.

Also add some explicit tests for check_consistency, it was missing in
the first place.

by adding  timeout in order to prevent an error from changing page before
finishing loading the iframed setting gadget

When pusing to for_testrunner_1 branch, we often have this failure on testFormPrintoutAsODT:

```
======================================================================
FAIL: test_field_replacement_with_variable (testFormPrintoutAsODT.TestFormPrintoutAsODT)
test variables replacement in ODT documents.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/slapgrid/slappart9/srv/testnode/zl/soft/4a13de8a0fdf926ddebab0387de0dc5e/parts/erp5/Products/ERP5OOo/tests/testFormPrintoutAsODT.py", line 1252, in test_field_replacement_with_variable
    self.assertEqual(node.text, value.strftime('%d/%m/%Y %H:%M:%S'))
AssertionError: '06/12/2010 11:33:15' != '06/12/2010 11:24:15'
```

After some investigation, turned out that:
* tests where always failing when running by `COMP-2544-3Nodes-ERP5PROJECT2` testnode
* This machine uses `SystemV/CST6CDT` as timezone
* the test fails in the same way when running locally with `TZ=SystemV/CST6CDT`

I belive this fixes, I tried running under `SystemV/CST6CDT`, `UTC` and `Europe/Paris`  TZ and it passes for all cases. 

/reviewed-on nexedi/erp5!174

/reviewed-on nexedi/erp5!175

Use of fail is now a coding crime

Since ODF dates are "timezone naïve", just calculate the timestamp with
the input date timezone as reference timezone.

I don't think the "XXX Works only if the timezone is the same in
OpenOffice" comment was true, so I just remove it.

It's better to explicitly specify the expected value, this test should
not depend on DateTime.strftime implementation, especially since this
implementation does some timezone conversion depending on time.tzname

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.