Upgrade of product list key, allowing for more search parameters

[monsieurtanuki]

Problem

For the moment, we store all the search parameters as a hive key, which has limitations (255 ASCII chars). Advanced search (#1371) means more search parameters than today. If we want to store searches with many parameters, we cannot use hive anymore because we'll probably break the 255 char limit. For the moment in the key we store the search terms (e.g. "pizza"), the country and the language. If we have more parameters, we have the re-think the way search parameters are stored.

Proposed solution

With sqflite we don't have that 255 char limitation we have in hive. Therefore a simple fix would be to migrate DaoProductList from hive to sqflite - the only potential problem I see is that we'll have to convert most methods as async (from what I read in the code the impact would be minimal and there's only one place where we'll need some tap dancing to manage the async) (namely with getLength).

In order to manage the increased complexity of the key (not just its bigger length), we could store the key as a json instead of a mere String concatenation. This will give us more flexibility - like "reuse a previous search parameters".

Additional context

With @g123k we already evoked the possible migration of DaoProductList to sqflite: nothing prevented it, it was just not a priority and the impact on the app would be limited.

For the moment, in hive the barcode list is stored as a json. Would it be interesting to store each barcode as a sqflite table row? Probably not in a first approach, because of the impact on reordering the items (less easy), on space (that means a new row with the barcode and the search key, for each product when it belongs to a list), and there's no visible added value regarding a specific feature.

Part of

• #1371