Catalog used in this test is now close/above 1k rows, so go one API level
down to get control over that pesky "limit 1000".

These tests do not test what they advertise anymore. Advertised features
are in widespread use in other tests, so there should be no need to test
specifically for these.
Also, avoids polluting other tests by clearing catalog for futile reasons.

ZSQLCatalog/ERP5Catalog is only supposed to work on catalog table, by
definition.

Also, reorder imports to follow python style: standard modules before
others.

Current scheme causes paths to exceed catalog limit.

Especially, stop using getToolByName.

Id generator is too expensive to use for such trivial purposes.
Also, this was using an API of id generator which should never have been
added.
Also, this was bogus on several accounts:
- if the tag as provided by caller (as seems to be supported), then
  newActiveProcess would have used an unrelated tag.
- if the alarm activity fails and gets re-run later, the wrong tag will
  also be used.
Instead, generate the tag with a random value.

This allow to customize browser look.

Make the label, listbox, panel more readable.

2.0.3 could not be installed because 'version.txt' was missing.

* form_list: Jump, Actions, Add, Export, Fast Input
* form_view: View, Actions, Export, Previous, Next
* form_view_editable: View, Actions, Add, Previous, Next

This allow to keep the previous/next links in all mode.

Move the delete functionnality to the action page.

Tic'ing mid-hot-reindex is not possible, so immediate reindexation is
not avoidable here. Also, immediate indexation of just-created document
is acceptable, so this is not exactly a bad example.

Fixed commit was part of a larger commit stack, and this fix was
mistakenly squashed in an unrelated commit, and hence did not make it to
master.

Intercepting an indexation activity is not reliable, as multiple indexation
activities may have been spawned, and the wrong may be intercepted here.
So instead, explicitly unindex the document intended to not exist in
catalog.

This is a very minimal support, as "flush" is kind of deprecated, only
surviving because tests need to be able to tell which activity may
execute, and there is currently no other way to support this.

Avoids logic duplication on how to store the environment.
Avoids relying on ERP5 products (for whatever it's worth anyway).

Also, simplify docstring.

Only PluggableAuthService import may not be importable, and is decisive
in importing from ERP5Security, which must then work.

Just like age is taken into account inside each activity queue.

Increasing priority value (hence making the activity execution priority
lower) means that all previously-spawned activities will have at least
started execution before the next batch of activities begins being
prepared. During that preparation, more activities will end, meaning there
is then unused processing node time, decreasing processing efficiency.

By making re-call activity have the same priority as spawned activities
will reduce this delay by making the re-call activity candidate for
execution at the same time as the latest activity batch, without leading
to activity queue size increase: older activities within a given priority
range still get precedence, so any older group will tend to finish before
more batches get spawned.

Measures on indexing 700k documents with 20 activity nodes:
- priority + 1: 84k documents indexed in the first 5 minutes,
  47k in the last 5 minutes. Average: 64k/5 minutes
- priority: 101k documents indexed in the first 5 minutes,
  97k in the last 5 minutes. Average: 99k/5 minutes
Peak speed (which is the initial speed) is 20% higher.
As the slowdown rate (likely coming from lower-priority activities piling
up in the message_queue table) is also much lower in the second case
(900 fewer documents indexed on each 5 minutes increment instead of 4k),
the overall average speed improves by 54%.