494 verify http client and connection reuse for recurrent calls to the same federation member

[keski]

This PR add support for HTTP connection reuse in:

• SPARQLRequestProcessorImpl
• TPFRequestProcessorImpl
• BRTPFRequestProcessorImpl
• RESTRequestProcessorImpl
• Neo4jRequestProcessorImpl
• GraphQLRequestProcessorImpl

For all request types except GraphQLRequestProcessorImpl the changes are minor, since the implementations for the connections were already built on java.net.http.HttpClient.

For GraphQLRequestProcessorImpl, there are more substantial changes in GraphQLConnection. During testing with a public endpoint I noticed that the raw key caused exceptions so removed it for now. (What is/was the purpose of this key originally? Is it related to Apollo and GraphiQL somehow?)

Btw, is there any documentation on how to setup the servers (and the data needed) for GraphQLRequestProcessorImplTest and Neo4jRequestProcessorImplTest?

The HttpClientProvider is currently in hefquin-base, but we may wish to move it before merge according to the ungoing discussion in #494.

[hartig]

Looks generally very good. Just a few comments.

[hartig]

For GraphQLRequestProcessorImpl, there are more substantial changes in GraphQLConnection. During testing with a public endpoint I noticed that the raw key caused exceptions so removed it for now. (What is/was the purpose of this key originally? Is it related to Apollo and GraphiQL somehow?)

I honestly have no idea. The whole GraphQL connector was written by a student under the supervison of @scferrada . I didn't look so closely at that code, but I remember that it is generally not as well-designed as the core parts of the engine. Using it for real would require quite a bit of additional work. In this sense, if you managed to make GraphQLConnection work now, then that's fine for the moment.

Btw, is there any documentation on how to setup the servers (and the data needed) for GraphQLRequestProcessorImplTest and Neo4jRequestProcessorImplTest?

I'm afraid not. But maybe @scferrada can provide some insight. He wrote the Neo4j connector. If I remember correctly, for these tests, he simply used an out-of-box Neo4j server with one of their demo databases.

The HttpClientProvider is currently in hefquin-base, but we may wish to move it before merge according to the ungoing discussion in #494.

As I mentioned over there, I would like HttpClientProvider to be moved to hefquin-access, but that may better be done in a new PR after this one is merged.

Something else that just comes to my mind:
Can you please update the Changelog in this PR to add a bullet point about the change done by the PR.

[keski]

Can you please update the Changelog in this PR to add a bullet point about the change done by the PR.

Absolutely. Changelog updated in cebeb7b.

[hartig]

Thanks a lot for addressing my comments!

The PR is ready to merge now.

Notice that I have removed issue #494 as being resolved by this PR. The remaining TODO still to be addressed in a follow-up PR is to reverse the dependency between hefquin-access and hefquin-pgconnector/hefquin-graphqlconnector, and then to move HttpClientProvider to hefquin-access. Can you please give this a try based on what I have outlined in the issue.