[dataquery] Fetch accessible instruments in a single query in the dictionary module

[HenriRabalais]

Description

/dictionary/categories (and /dictionary/module/<name>) scaled linearly with the number of distinct visit labels in the database. getUserModuleCategories() built the set of instruments the user can access by running one Utility::getVisitInstruments() query per visit label, and each of those queries joins session, candidate, flag and test_names.

This replaces the per-visit loop with a single query that fetches the distinct instrument names across all of the user's visits. The query returns names only, since the result is only used to check whether an instrument is in the list.

Changes

• Replaced the per-visit foreach loop in LORIS\dictionary\Module::getUserModuleCategories() with a single query over all of the user's visits
• The query returns Test_name only, so Full_name is no longer fetched

Testing Instructions

1. Use a database with a large number of distinct session.Visit_label values.
2. Log in and open the Data Query Tool, or request GET /dictionary/categories directly.
3. Confirm the endpoint now returns quickly rather than blocking for tens of seconds.
4. Confirm the instrument categories shown in the tool are the same as before this change (the response body should be identical).

Related Issues

Closes #11166. The slow loop was introduced in #9903.

[HenriRabalais]

@marandmart can you take a look at this when you have the time?

[ridz1208]

@HenriRabalais can you please rebase this to 29.0-release

[marandmart]

LGTM!

[driusan]

This table is not accurate for the full name. The source of truth for the full name is NDB_BVL_Instrument::getFullName(). (For instance, for LINST instruments it comes from parsing the file, and for a php instrument it could just return a hardcoded string.)

I think you need to:

1. Not join this table (it's unnecessary)
2. Call the NDB_BVL_Instrument::factory(testname)->getFullName() for each

(This shouldn't be slower, unless there's too many instruments using LegacyInstrumentTrait instead of implementing getFullName() themselves..)

I also think this function should be moved into the dictionary module where it's used or inlined (not for efficiency, just because having both getVisitsInstruments and getVisitInstruments next to each other in the Utility class is confusing, and there is only one call site.. also you have access to the LorisInstance object there to get a database connection.)

[HenriRabalais]

@driusan

thanks for the review!

I've now realized the full name isn't used at this call site at all. getUserModuleCategories() only checks whether each instrument is in the list, and the category names already come from getFullName() in InstrumentQueryEngine::getDataDictionary(), so there's nothing to call getFullName() for. I've removed Full_name from the query. I kept the join to test_names only to get Test_name, since flag just has TestID, so let me know if you had another way of getting the name in mind.

I moved the query into getUserModuleCategories() and removed Utility::getVisitsInstruments(), as you asked.