SPARQL Federated Query support

[dpetran]

SPARQL Federated Query Support

Demonstrate a local/remote join using a SPARQL SERVICE query clause.

Also refactors our http router and adds support for ledger-specific requests.

Ledger specific request support

Now you can address a specific ledger via URL, which is critical for SPARQL SERVICE clauses - you cannot specify custom headers or payloads within the syntax provided, so the URL needs to contain all the information necessary to properly resolve the ledger or graph the query needs.

The ledger-specific requests are available via these paths:

/fluree/ledger/<ledger-alias>/<operation>

Requests with URIs that match this path are rewritten to target the more general endpoint and the ledger-alias is supplied as a fluree-ledger header, and then rerouted. For example, a POST /fluree/ledger/my/ledger/query is rerouted to /fluree/query with the added fluree-ledger: my/ledger header (overriding any supplied fluree-ledger header.

Implementation notes

After looking at #174, I decided to implement similar functionality but with an approach that requires less code and that is more performant. All ledger-specific requests are rerouted transparently by the ledger-specific-handler so that we maintain the same middleware stack and all operations are handled the same, regardless of how they are addressed.

I've chosen the path prefix /fluree/ledger/<ledger-alias> for our ledger-specific routes instead of /fluree/<ledger-alias> in order to avoid "conflicting" routes, which come with a performance penalty.

https://github.com/fluree/core/issues/207
fluree/db#1134

[bplatz]

For the reasons I noted in the other PR I don't think this endpoint approach is ideal. It creates inconsistencies between a ledger I visit via a webpage and then how it is used. It also slightly complicates developer experience because I can't just append methods to an api URL but need to reconstruct every method I want to use. It gets away from "Resource" semantics which I think is valuable.

Not sure the breadth of the benefits of our router config this approach makes, and I'm sure there is a balance that has to be weighed, but I'd much rather put extra weight on DX and semantics than chosen library patterns in that balance.

[dpetran]

This approach was because I had to get something working quickly, and after about 90 minutes of faffing trying to get the other approach to support POST queries I binned it and whipped this up. I still think that the simplicity and performance of this approach are worth a lot, but this wasn't intended as a production implementation, just what was necessary for the demo.

[zonotope]

🍏