Revert commits pushed by mistake

Revert "fix undefined variables"

This reverts commit 77a53809e6015f41ca84e1154c0ffa5a74958364.

Revert "Listbox: calculate a mapping uid -> object once"

This reverts commit 84029c01e1c7e45f354aa9f7236772c05e0e1b01.

Revert "fix list method returning duplicate uids"

This reverts commit 386b0e6bf6f6a7251781f2b1e5232d7776619c49.

Revert "test for dialog listbox with editable fields"

This reverts commit e046d8f51c2bc7ce600a91d901ee7d9c04008d73.
coding crime : never use the expression "if obj" whenever obj is not a simple type.

this code was working just by chance because active_knowledge_pad is a brain, not an ERP5 object.
optimise ERP5Site_getKnowledgePadListForUser.

call getObject() once explicitly to reduce number of calls.
fixup e9b75a2762 (optimise ERP5Site_getKnowledgePadListForUser).
Use REPLACE rather than INSERT for DELETE..INSERT indexation pattern.

When a document gets rows inserted in category table while there was none
before (typically: first document indexation), it may trigger
  IntegrityError: (1062, "Duplicate entry '...' for key 'PRIMARY'")
because in the DELETE..INSERT pattern, DELETE finds no matching rows and
does not gap-lock (because we enable innodb_locks_unsafe_for_binlog), then
the second INSERT happening, chronologically speaking, waits for the
transaction of the first to e committed, and on commit it causes such
duplicate key error.

A transient visible effect of this change is that if both competing
indexations see a different document state (because document got modified
in some 3rd transaction), the union of the resulting set of rows will be
visible until the reindexation which must have been triggered by the 3rd
transaction gets executed, at which point only the latest set will be
visible.

A similar issue exists before this change, with stricter conditions: it
needs the intersection of both sets to be empty, because a non-empty
intersection causes the duplicate key error solved here.

This change has been measured to improve scalability of an invoice building
test case (naturally triggering indexations) starting from ~12 activity
nodes:
   8 nodes:  +1.4% invoices/hour
  12 nodes:  +9.5% invoices/hour
  16 nodes: +12.3% invoices/hour
(values are the difference between DELETE..INSERT and DELETE..REPLACE)