[semantic-data-provider] Fix fetchContainer queries

[mguihal]

Hello,

I propose a bugfix here when using the getList method of the semantic-data-provider.

Bugs fixed

• When the getList is performed on several containers, only the results from one of the containers are returned.
• When the _predicates filter is added to the query, no results are returned.
• The number of total results returned in the pagination response is not correct

Corrections I've split the PR into 2 commits, the first one 73bd0923d2b2bc547fed6dbff416e008abf33243 contains the corrections I made for these issues.

For the first problem, it came from results = [].concat.apply(...results); with an incorrect use of apply. I replaced it with a flatMap a few lines below.

For the second problem, we iterated over each of the filters, and if one didn't match either a full-text search (q) or an attribute present in the resources, the resource was not taken into account. I changed to process the full-text search first, then iterate on the other attribute-based filters, ignoring the special filters (q, _predicates, _servers).

The _predicates filter (https://semapps.org/docs/frontend/semantic-data-provider/#filters) was not taken into account, so I implemented it as well.

For pagination, the total results returned corresponded to the total before filtering, not after.

Typescript conversion As with each of my interventions in this repo, I took the opportunity to convert the file to Typescript, with this commit 55fbf463d87934322d0b1b5059b170c1ae71ad0e

While typing, I realized that the results returned by Semapps contained a "type" attribute and not "@type" like the JsonLD specification, so the fetchContainer has to handle both cases, which makes typing a little more complex. Perhaps the Semapps LDP service should be modified to return the correct @type attribute 🤔

Similarly, I noticed the following filter, which isn't documented anywhere. I've kept it for now, but I'd be tempted to delete it to keep consistency and remove any special development. Moreover, it uses the "type" attribute and not "@type", so it's compatible with Semapps, but not with the specification.

// For SPARQL queries, we use "a" to filter types, but in containers it must be "type"
  if (filters.a) {
    filters.type = filters.a;
    delete filters.a;
  }

[simonLouvet]

I agree that ldp containers should return standard attributes like "@type" and "@id" instead of "type" and "id". @srosset81 , do you remember why type is returned by semapps (the architectural and strategic reason, not the technical reason of the context that formalizes the equivalence)?

[srosset81]

We must support both type and @type because the ActivityStreams JSON-LD context converts @type to type. Furthermore, we are forced to use this context if we want to communicate with other ActivityPub servers. The long-term solution would be to use a solution like LDO, which can adapt to any JSON-LD context and provide typing. This is something we plan to do if our new grant submission at NLnet is accepted.