due to fc05b33b

<u> tag does not exist in the standard used by erp5_web; use something which
should be equivalent

Because they are not delivery and the implementation would have to be different

We don't show stocks of services

To reveal invalid html in erp5_web's language selector

This partially reverts fac0ba5a

Otherwise, user gets redirected to site root with a login error.

Revert "Test deferred style with converting to a format"

This reverts commit cbfa8d56.
-> pushed by mistake

Revert "Set cloudoo on preferences in ERP5TypeTestCase"

This reverts commit 28824962.
-> pushed by mistake

Revert "Listbox from Folder_viewWorkflowActionDialog has hidden columns"

This reverts commit 802d3f53.
-> a test is failing

This partially reverts fac0ba5a

to avoid conflicts and to improve disk space efficiency.

(instead of source/destination section which was not working)

For easier debugging, so we don't have to know how python mangles
double-underscore properties, as introspection is reduced by __slots__
usage.
Suggested by Julien Muchembled <jm@nexedi.com>

So that creating an ActiveWrapper (or Method) once and reusing it to spawn
several activities gets a larger speed-up.
Message class API is not supposed to be used outside this module, so
drop failing test rather than fixing it.

Also, inherit from "object" as __slots__ are a new-style-class feature.

Also, provide one argument per line.
Also, avoid shadowing "id" built-in.

isMessageRegistered duplicates work done in registerMessage, so it wastes
time when creating an activity (in the likely event the activity is not a
duplicate).

It is (likely) already known to caller, is only used to look up an option
which is rarely enabled, and it turns out to be (relatively) expensive.

UPDATE query is exected to use the existing index on (processing_node,
priority, date) both for WHERE and ORDER BY, as is expected from
EXPLAIN-ing the equivalent SELECT:

MariaDB [erp5]> explain select uid from message_queue WHERE processing_node=0 AND date <= '2013-06-06 22:22:49' ORDER BY priority, date LIMIT 1;
+------+-------------+---------------+------+----------------------------------------------------------+-------------------------------+---------+-------+-------+--------------------------+
| id   | select_type | table         | type | possible_keys                                            | key                           | key_len | ref   | rows  | Extra                    |
+------+-------------+---------------+------+----------------------------------------------------------+-------------------------------+---------+-------+-------+--------------------------+
|    1 | SIMPLE      | message_queue | ref  | processing_node_processing,processing_node_priority_date | processing_node_priority_date | 2       | const | 26622 | Using where; Using index |
+------+-------------+---------------+------+----------------------------------------------------------+-------------------------------+---------+-------+-------+--------------------------+

If it weren't using the index for ORDER BY, "Extra" would contain
"Using filesort".

Still, UPDATE behaves differently:

  # User@Host: user[user] @  [10.0.0.3]
  # Thread_id: 1635880  Schema: erp5  QC_hit: No
  # Query_time: 2.668405  Lock_time: 2.460698  Rows_sent: 0  Rows_examined: 49263
  # Full_scan: No  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
  # Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0
  SET TIMESTAMP=1370557446;
  UPDATE
    message_queue
  SET
    processing_node=12
  WHERE
    processing_node=0
    AND DATE <= '2013-06-06 22:24:04'
    ORDER BY
    priority, DATE
  LIMIT 1;

So change the UPDATE..SELECT pattern into a SELECT FOR UPDATE..UPDATE
pattern, so SELECT's correct execution plan is used.

that should be part of commit 9b5c74fb ('force' argument in
BusinessTemplate._install() should not mean clear catalog. we can and
should use 'update_catalog' argument instead to clear catalog).

we can and should use 'update_catalog' argument instead to clear catalog.