HTTP worker refactoring

[nck-mlcnv]

SPARQLProtocolWorker is a draft for a better, more reliable worker that is tailored towards SPARQL Protocol. Each worker uses a single HttpClient and handles work completion conditions itself. It also covers sending and receiving HTTP request and request bodies that exceed 2GB.

This PR gives an idea what the internals of such a worker could look like. It doesn't provide a full implementation and the code is not yet used within IGUANA.

TODOs:

• [x] Complete TODOs in SPARQLProtocolWorker
• [x] Make SPARQLProtocolWorker configurable (and remove all other workers for now)
• [x] Implement LanguageProcessors for xml, csv and tsv SPARQL results -> move to separate issue
• [x] Port LanguageProcessor for RDF results -> move to separate issue
• [x] Adjust Stresstest to start SPARQLProtocolWorkers
• [x] Adjust Streestest to start a ResponseBodyProcessor per unique (QuerySource,LanguageProcessor)
• [x] write/update tests for all classes touched
• [x] document adjusted behavior
• [x] Ask @MichaelRoeder for a review of BigByteArray{Input,Output}Stream after tests are implemented for them
• [x] Use LSQ to decide if a query is an update query; if yes, use the update endpoint -> move to separate issue

Future improvements:

• allow to select language processors for: RDF and SPARQL-RESULT for each worker. The SPARQLProtocolWorker does content type negotiation based on info from LSQ about the query (basically: if it is a construct query, expect RDF)
• Make ResponseBodyProcessor configurable, including timeout for processing after querying is done and number of threads

[nck-mlcnv]

Some tests, that use JUnit 5, don't run on github appearently. It might have something to do with the mixed usage of junit 4 and 5.

[nck-mlcnv]

Hi, thanks for the review, I will look into the change requests soon.

[nck-mlcnv]

I accidently enabled the BigByteArrayStream tests, and it looks like they cause some issues on the GitHub system. 🤔