zope.{interface,component} implement Interfaces through __implements__,
__implemented__ (both implementedBy instances) and __provides__ (ClassProvides
instance) attributes set on the class itself through implementedByFallback
(zope.interface.declarations).

However, this implementation creates circular references by referencing the
class itself and thus erp5.* classes (and all its Accessors instances) were
never GC even after a reset.

When running testXHTML and installing the Unit Tests bt5s:
  * After 10 resets:  21MB leak (~  7% of Zope process USS).
  * After 20 resets:  70MB leak (~ 18% of Zope process USS).
  * After 28 resets: 122MB leak (~ 26% of Zope process USS).

If it is the case *and* the action script does not redirect, the password will be
in user's browser history.
There can be two different reasons to not redirect:
- not following the API (ie, intentionally not redirecting)
- letting an exception reach ZPublisher
Also, if the non-redirection causes an HTML page to be rendered, resources
loaded by that page will have a referrer containing the password, leaking it
to potentially foreign servers.

Before fixing this bug, 'listbox_previousPage:method' input button was
submitted but with no value (''). However, this was not handled by the
backward-compatibility code and thus next/previous page buttons would
not work properly if erp5_xhtml_style is not updated.

ListBox: Navigation methods should not be created when rendering ListBox (#20161014-741678).

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.

/reviewed-on nexedi/erp5!69
Conflicts:
	product/ERP5/bootstrap/erp5_core/DocumentTemplateItem/portal_components/document.erp5.ScriptConstraint.py

Portal Type as Classes: Fix memory leak: Workflow method list was never emptied and thus reset Workflow Methods were never GC.

A bug fix of erp5_core/Folder_delete

See merge request !65
Conflicts:
	product/ERP5/tests/testERP5Core.py

Submit action must be disabled while solver is being updated. End user sometimes click too fast that submit action fails due to lack of 'my_tested_property_list'.

Conflicts:
	bt5/erp5_simulation_fast_input/SkinTemplateItem/portal_skins/erp5_simulation_fast_input/gadget_solve_divergence_dialog.js.xml

Selection.__call__() calls getParams() and as getParams() can be called
directly from many places (such as SelectionTool.getSelectionParamsFor()),
it makes more sense to have it here.

This reverts commit b78933f1.

1. On Tab1, from PurchaseSupply_view, click on 'Purchase Supply Lines':
   Base_viewListMode??proxy_form_id=PurchaseSupply_view&proxy_field_id=listbox

   This Python Script initialise 'list_mode_proxy_selection' with the
   above 2 GET parameters and then displays PurchaseSupply_view.listbox
   indirectly but current Form is Base_viewListModeRenderer.

2. On Tab2, from SaleSupply_view, click on 'Sale Supply Lines':
   Base_viewListMode?proxy_form_id=SaleSupply_view&proxy_field_id=listbox

   This Python Script initialise 'list_mode_proxy_selection' with the
   above 2 GET parameters and then displays SaleSupply_view.listbox
   indirectly but current Form is Base_viewListModeRenderer.

3. On Tab1, filter Purchase Supply Lines.

   As proxy_form_id and proxy_field_id are not given, then
   Base_viewListModeRender fallbacks on 'list_mode_proxy_selection'
   values to find out the Form ID to be called and wrongly display
   SaleSupply_view.listbox (2.).

Rather than the acquired Property.

Instead, define default values if not set (same as previously hardcoded
ones) and get the value(s) define on the Tester instead as we may want
to check only variation_category_list and not variation_property_dict
for example...

Followup of: "simulation: improve equivalence testers explanations messages".

Followup of: "simulation: improve equivalence testers explanations messages".

erp5_simulation: Display Divergence dialog even if there is nothing to solve (same as legacy Simulation Dialog).

This fixes the following Site Error when there is no Divergence to solve:
  AttributeError: 'NoneType' object has no attribute 'SolverProcess_getSolverDecisionList'

This may happen if user selects 'Solve Divergence' Action and solve
Divergences, then immediately goes back and selects again this action
whereas there is actually no Divergence to solve.

Selection.__call__() calls getParams() and as getParams() can be called
directly from many places (such as SelectionTool.getSelectionParamsFor()),
it makes more sense to have it here.

This reverts commit 5fac6732:

  When the Divergence is solved and user goes back to the main view, the
  button is visible but when user clicks ont it and if Activities have
  been processed in the meantime, this will raise an AttributeError
  because newSolverProcess returns None and there is nothing to display.

  This happens even when adding Delivery_isDivergent() as a guard
  because it still returns True if Activities are running in background.

count_method was removed from Base_viewFieldLibrary/my_view_mode_module_listbox
used by Resource Module ListBox (76282344) for performance issues when
countFolder is called with a Module containing > ~50k documents but this
should not be relevant for Resource Modules.

Followup of: "simulation: improve equivalence testers explanations messages".

simulation: MultiPropertyEquivalenceTester was missing from Variation Divergence Tester Portal Type.

Followup of: "simulation: improve equivalence testers explanations messages".

With Legacy Simulation, when Adopting Prevision, the Builder was called
again and the value was set either at Delivery, Line or Cell level
according to the Movement Group definition. Implement the same kind of
behavior for New Simulation.

With ZODB Components, getBusinessTemplateList() only returns the test
bt5 (as given on the command line, such as BT_TITLE:testFoo) and later
it resolves dependencies.

So filtering bt5 to be updated should be done as late as possible...

Followup of: "simulation: improve equivalence testers explanations messages".

Followup of: "simulation: improve equivalence testers explanations messages".

Followup of: "simulation: improve equivalence testers explanations messages".

Followup of: "simulation: improve equivalence testers explanations messages".

This makes more sense as all Tester inherits from EquivalenceTesterMixin,
even project-specific EquivalenceTester classes.

Followup of: "simulation: improve equivalence testers explanations messages".

* 2a188797: "simulation: improve equivalence testers explanations messages"
* df04eb69: "Implement delivery.getQuantity() == 0."

Default values for tested_property and tested_property_title must not
be of type tuple any more since theses properties are no longer multi
valued

With latest simulation, the explanation given to user when solving a
divergence was not good enough :
- Property ids were displayed without possibility to display
  business word (like displaying 'stop_date' instead of
  'Delivery Date'
- Some message was displayed in the solve divergence dialog whatever
  was the equivalence tester behind. Therefore, customizations of
  messages made a equivalence tester level were not displayed to user

Therefore, following was done:
- in solve divergence dialog, include the message generated by the
  equivalence tester
- use tested_property_title to allow using business words to describe
  properties having divergence
- most equivalence testers are written in a way to evaluate divergence
  on a single property. To have better UI configuration of such equivalence
  testers, change tested_property and tested_property_title properties
  type from "lines" to "string". This required to add some backward
  compatible code.
- use Variation Divergence Tester to show a case of an equivalence
  tester using different properties. For this, add a property sheet
  dedicated to multi properties equivalence testers
- update propertysheets to allow translating tested_property_title

Conflicts:
	product/ERP5/Document/DateTimeEquivalenceTester.py