GH-3510: Sparql Adapter System

[Aklakan]

GitHub issue resolved #3510

Pull request Description: Updated proposal for custom SPARQL adapters over DatasetGraphs based on #3184 .
The goal is to unify local and remote query execution on the DatasetGraph level in a way that allows for efficient query/update execution by possibly offloading the execution work to an external or remote engine. This way, execution tracking on the dataset graph (using its Context) level should thus work for both local and remote workloads.

The main difference to the previous proposal is, that unification happens at the builder level - i.e. QueryExecBuilder and UpdateExecBuilder. SparqlAdapter, as the DatasetGraph-specific factory for those builders, is the ARQ-level driver interface for implementing custom sparql execution over a DatasetGraph.

A generic SparqlAdapter for RDFLink is provided. This adapter design is aimed at making any future vendor-specific RDFLink extension immediately available on the ARQ level. Conversely, new implementations of SparqlAdapter - while possible - should be avoided in favor of RDFLink-based implementations.

The class ExampleDBpediaViaRemoteDataset.java demonstrates the system: A query with Virtuoso-specific features is passed through the Jena API to the DBpedia endpoint, a custom execution wrapper is applied, and yet the outcome is a QueryExecHTTP instance that allows for inspecting certain HTTP fields.

String queryString =
	"SELECT * FROM <http://dbpedia.org> { ?s rdfs:label ?o . ?o bif:contains 'Leipzig' } LIMIT 3";

DatasetGraph dsg = new DatasetGraphOverRDFLink(() ->
	RDFLinkHTTP.newBuilder().destination("http://dbpedia.org/sparql").build());

try (QueryExec qe = QueryExec.newBuilder().dataset(dsg).query(queryString)
		.timeout(10, TimeUnit.SECONDS).transformExec(e -> new QueryExecWrapperDemo(label, e)).build()) {
    // ...
}

Remote Execution Deferred: Dataset type: DatasetGraphOverRDFLink
Remote Execution Deferred: QueryExecBuilder type: QueryExecDatasetBuilderDeferred
Remote Execution Deferred: QueryExec type: QueryExecHTTPWrapper
Remote Execution Deferred: Execution result object type: RowSetBuffered
---------------------------------------------------------------------------------------------------------------------
| s                                                                        | o                                      |
=====================================================================================================================
| <http://dbpedia.org/resource/1._FC_Lokomotive_Leipzig>                   | "1. FC Lokomotive Leipzig"@en          |
| <http://dbpedia.org/resource/Category:1._FC_Lokomotive_Leipzig>          | "1. FC Lokomotive Leipzig"@en          |
| <http://dbpedia.org/resource/Category:1._FC_Lokomotive_Leipzig_managers> | "1. FC Lokomotive Leipzig managers"@en |
---------------------------------------------------------------------------------------------------------------------

Probably the most critical changes are:

• QueryExecBuilderDataset and QueryExecHTTP are now interfaces.

---

• Tests are included.
• [ ] Documentation change and updates are provided for the Apache Jena website
• Commits have been squashed to remove intermediate development commit messages.
• Key commit messages start with the issue number (GH-xxxx)

By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.

---

See the Apache Jena "Contributing" guide.

[Aklakan]

Overall I'd say the proposal is in a state where it can be reviewed.

The part I that I am not totally sure about whether the (public) transformExec methods are really needed at this stage, because post transformations of execs could also be hard-wired into the build method of builders.
I.e. during build, check the context for some key(s) and apply the exec transforms.
However, the indirection with QueryExecHTTPWrapper would still be needed in order to transparently modify a QueryExec while still exposing the HTTP fields.