SPARQL UPDATE: Fixes Halloween problem

Buffers all SPARQL UPDATE operation for DELETE/INSERT in order to avoid this problem.

This is quite heavy but RocksDB transaction already stay in memory, hence it won't change a lot the operation complexity.

The unit test for this problem was bad because the optimizer was hiding the problem.

lib/src/sparql/update.rs

@@ -131,8 +131,9 @@ impl<'a, 'b: 'a> SimpleUpdateEvaluator<'a, 'b> {
             Rc::new(self.options.query_options.custom_functions.clone()),
         );
         let mut bnodes = HashMap::new();
-        for tuple in evaluator.plan_evaluator(&plan)(EncodedTuple::with_capacity(variables.len())) {
-            let tuple = tuple?;
+        let tuples = evaluator.plan_evaluator(&plan)(EncodedTuple::with_capacity(variables.len()))
+            .collect::<Result<Vec<_>, _>>()?; //TODO: would be much better to stream
+        for tuple in tuples {
             for quad in delete {
                 if let Some(quad) =
                     Self::convert_ground_quad_pattern(quad, &variables, &tuple, &dataset)?

testsuite/oxigraph-tests/sparql/halloween_problem.ru

@@ -1,3 +1,3 @@
 PREFIX ex: <http://example.com/>
-INSERT DATA { ex:s ex:salary 1200 . ex:s2 ex:salary 1250 . ex:boss ex:salary 1600 . };
+INSERT DATA { ex:s ex:salary 1200 . ex:s2 ex:salary 1250 . ex:s3 ex:salary 1280 . ex:boss ex:salary 1600 . };
 DELETE { ?s ex:salary ?o } INSERT { ?s ex:salary ?v } WHERE { ?s ex:salary ?o FILTER(?o < 1500) BIND(?o + 100 AS ?v) }

testsuite/oxigraph-tests/sparql/halloween_problem_result.ttl

@@ -2,4 +2,5 @@
 
 ex:s ex:salary 1300 .
 ex:s2 ex:salary 1350 .
+ex:s3 ex:salary 1380 .
 ex:boss ex:salary 1600 .