[devtools/test] Skip qunit tests in case of timeout Follow-up on 87443f279b0f where other similar tests got adjusted not to fail (in particular in our CI environment).

[autoform] Avoid two calls to field.process_form for the same field in some cases when some entity is being created and data include non-inlined relations, the values for this relation are now stored for later usage, avoiding two calls to field's process_form method, which may be unexpected for custom fields. This has been discovered in saem_ref#f5444b1f9770. Reorganize imports in the test along the way.

[pyramid] Don't use unsafe_cnx_context_manager for write queries we may have clumsy error that hide previous problems on attempting to commit the transaction. Closes #16753531

Repair database wrt indexes / unique constraints * recreate indexes dropped by 3.23 migration (but it's still unclear why) * attempt drop remaining extra indexes (there may be a bunch of these on old instances) * warn about missing expected indexes Closes #16666137

Enhance postgres index filter with values from real life This has been found on fairly old instances of ours (cwo/elo). Dunno if we really want this in, it may lead to false negatives.

Extract functions to list expected/found database indexes from check_indexes so they may be used from other contexts. Use consistent naming along the way: always use indexes, not indices.

Simplify and fix _cw.drop_entity_cache * it's never called with an eid as argument, beside in a useless case in test (removed) * the only place where it's called from outside the tests is in full-text reindexation in server.checkintegrity: we could removed the request implementation and move it in unittest_rset, byt I decided to keep it for consistency with all other entity cache handling methods * get back a fix from Julien Cristau for the connection's implementation, quoting is commit message: When removing an entity from the transaction's cache, clear the entity's own cache May avoid issues where an entity object is still accessible somewhere else (e.g. an operation) after dropping it from the transaction's cache, with a stale attribute or relation cache.

[entity/optimization] Cache rset when entity.related is called with entities=False If fail to see why we couldn't cache in this case, while this is important for optimization reason: when doing a single HTTP request, some queries are done two or three times because of predicates / uicfg or alike. Also always store tuple and not list in the cache, because: * else we get some regression * and inconsistent result type (tuple or list) * and it simply feels better to cache an unmutable object.