Race conditions are likely to happen with CMFActivity between message tables
are automatically upgraded during bootstrap.

Most code is moved from DA patch to ZMySQLDA.

For even more refactoring between SQLDict & SQLQueue,
which now uses SQL tables with the same schema.

The action to recreate activity tables while preserving existing messages
was unsafe for 2 reasons:
- if any error happened, messages could be lost
- it relied on Message.reactivate

Which this patch, any instance created after commit d881edd1 (Aug 2010) will
upgrade successfully. For older instances, make sure you have no activity left.

For cases where 'ALTER TABLE' would not work, a better way to implement repair
functionality would be:
- one action to backup all messages in ZODB
- and another to restore them
And maybe a security so that during the backup-clear-restore sequence,
activities can't be created nor processed.

If any column is added in the future, it would still be possible to write code
that fills them by inspecting messages.

This is not perfect. There can still be dummy 'MODIFY COLUMN' when the order
of columns changes.

Previous code would have failed if 'activate_kw' was already present
(TypeError: ... got multiple values for keyword argument '...').

Now that ZSQLCatalog accepts to index an object whose path is "deleted" in the
catalog, we must protect against any misuse or bug of CMFActivity.

This uses much less memory

basically, rewrite :
self.assertEqual(result_of_complex_method, result_of_another_complex_method)
into:
self.assertEqual(expected_value, result_of_another_complex_method)

This allow to get localstorage compatibility with binary files.

erp5_accounting: Improve code to only consider the line that has source and destination section equal the transaction in context

This reverts commit 985b8a77 as unit tests dependencies is now fixed

[erp5_web] Partial revert "Allow to configure ERP5 frontpage gadget, hateoas URL and application title."

This reverts commit e4bfb062.

Those files were commited by mistake.

This reverts commit d0d7fac6.

This reverts

    4f3bb0c9    (Revert "BigFile: Fixes, Tests and on-server Append support")

and thus continues the story of

    193f5cdd    (BigFile: Fixes, Tests and on-server Append support)

and essentially restores the result of that merge.

Initial idea was to give people time to better see how to handle code
submisstion, but in the end Romain approved it as is.

Reference: https://lab.nexedi.cn/nexedi/erp5/merge_requests/5 (= merge request !5)

The configuration is done on the WebSite level.
No custom JS code is needed.

This reverts commit 193f5cdd, reversing
changes made to 4ee61a23.

Jean-Paul suggested we first better further review our code review / merging
procedures and use e.g. this particular merge request as a basis for that.

Thus I'm reverting this merge, so people could study and re-merge it
"properly".

~~~~

Please note: I could potentially rewrite master history so that there
would be a no merge commit at all, as e.g. my branch was not so far ever
merged at all. In contrast to draft branches, that is however a not good
practice to rebase, and thus rewrite, master history - what has been
committed is committed and we only continue.

So later to re-merge my branch, if it will not be changed, we'll need to
first revert this revert (see [1] for rationale), or alternatively I
could re-prepare my patches with different sha1 ids and they will merge
again the "usual way".

[1] http://git-scm.com/docs/howto/revert-a-faulty-merge.html

The configuration is done on the Web Site level, to reduce the need to write custom JS code.