The set of resources correponding to a given (non-strict) use is generally
constant, while the number of documents having relations to these
resources will increase over a site's life.

The original query used 2 joins:
- catalog to category for document/resource relation
- category to category for resource/use relation

Given several tables joined together, MySQL query optimiser will try
to first execute a query on the table which will yield the fewest rows.

As a result of all the above, query optimiser would end up choosing to
first find which resources have a use relation to given uid, and only after
find which documents have a resource relation to these. Which means it
cannot use any index on the documents themselves, and only an index
on resource's use... Leading to extremely poor performance on large data
set when, for example, trying to list the few documents in a given state
which also have a resource of selected use.

Instead, lookup the list of resources per (non-strict) use when building
the domain tree, and put that pre-computed uid list as membership
criterion: catalog query is then only a single-join, whose execution is
trivial to plan.