Faster filtering, mapping, limiting, skipping and wrapping

[jacoscaz]

This PR contains all work from #48 , #49 , #53, #54 and #55 done by @jeswr and I on performance. It's not ready to be merged but it is ready for reviews and feedbacks.

Jesse and I opted to merge everything into one branch as, having validated all of these PRs individually, we now need them in aggregate to measure their overall effect and to facilitate testing within other projects, including Jesse's performance evaluations for his honors work.

As for the state of this PR, all asynciterator tests are passing and so are Comunica's spec:query and spec:update suites. As per #49 (comment) , these are the issues within Comunica:

• There's one test suite that passes a set of initial quads as an empty object, which breaks wrapping https://github.com/comunica/comunica/blob/448bfbadd805dcad95841789cd12b0d33a672585/packages/actor-rdf-resolve-hypermedia-qpf/test/ActorRdfResolveHypermediaQpf-test.ts#L103 . Fixing this one is easy, just change the test to make that an empty array.
• There's one actor that uses the protected method BufferedIterator#_fillBuffer(), which is not available anymore as after these PRs there's no guarantee for wrap() to return an instance of BufferedIterator (and we shouldn't use protected methods anyway) https://github.com/comunica/comunica/blob/448bfbadd805dcad95841789cd12b0d33a672585/packages/actor-query-operation-sparql-endpoint/lib/ActorQueryOperationSparqlEndpoint.ts#L168 . Fixing this one might not be as easy but I don't have a clear idea of what's going on.
• This test https://github.com/comunica/comunica/blob/448bfbadd805dcad95841789cd12b0d33a672585/packages/actor-query-operation-sparql-endpoint/test/ActorQueryOperationSparqlEndpoint-test.ts#L410 is breaking due to a timeout while expecting an error event. This might be due to something missing in how we relay errors within these PRs.

[coveralls]

Coverage decreased (-1.5%) to 98.452% when pulling 3789177 on jacoscaz:faster-filtering-mapping-limiting-skipping-wrapping-union into 358608f on RubenVerborgh:main.

[RubenVerborgh]

Thanks @jacoscaz and @jeswr!

I'm not sure one big PR is the best thing though if you still want me to understand everything 😅
But perhaps it's indeed good to iterate on this until it is in perfect shape, and then we can break this into bits as needed.

[jacoscaz]

But perhaps it's indeed good to iterate on this until it is in perfect shape, and then we can break this into bits as needed.

Yep, we can always break it down into separate PRs later on, if needed.

[jacoscaz]

Closing this in favor of #59 and the plan detailed in #44 (comment) .