feat: add APQ plugin

[chrfritsch]

I would like to add an automatic persisted query plugin the plays nicely together with https://www.apollographql.com/docs/react/api/link/persisted-queries, for example.

[Kingdutch]

Cool idea! Some reviewer thoughts:

1. I think it would be a good idea to add test coverage here so we know it adheres to what Apollo expects (and keeps doing this in the future).
2. This should probably be an opt-in feature, rather than enabled for everyone. This may not be desirable in all GraphQL server applications. If I read the Apollo description correctly then one way that I could exploit this for example as an malicious client is to send a slightly different hash and query each time to quickly fill up the database cache table and cause a DoS attack.

[chrfritsch]

2\. This should probably be an opt-in feature, rather than enabled for everyone. This may not be desirable in all GraphQL server applications. If I read the Apollo description correctly then one way that I could exploit this for example as an malicious client is to send a slightly different hash and query each time to quickly fill up the database cache table and cause a DoS attack.

I think it is an opt-in feature because you have to enable the plugin on admin/config/graphql/servers/manage/[server]/persisted_queries.
About the DoS I am not sure. Because that's the point of automatic persistent queries, that you don't have to define them on the server-side. And instead, your frontend can query what it needs. I think the DoS problem then has to be solved by your infrastructure, that your server only accepts requests from the same domain for example.

[chrfritsch]

@Kingdutch @klausi I would like to hear more feedback on this.

[Kingdutch]

Thanks for the improvements and for requesting feedback! I think we can improve the robustness of this feature by taking a closer look at what Apollo does for its own server implementation.

[Kingdutch]

I didn't compare to the Apollo server source code a second time (I don't have the time at the moment but didn't want to let you wait longer).

The code as-is looks good to me. I added one nitpick based on my own PHPStan usage for an error that only shows up with "strict rules" enabled. We don't have that in this module so I'm fine either way. The change in the ServerInterface perhaps requires a bit more debate, but that line change can be undone and discussed without blocking this issue further (since the issue it's attempting to fix is not caused/changed by this PR).

With regards to the security implications I raised at the start of the PR, I'm satisfied with this being an opt-in feature that people themselves can only enabled when they're dealing with known and trusted clients (enforced through the existing GraphQL permission system).

[Kingdutch]

This would technically be a breaking change. Since the following code would break:

foreach ($this->getPersistedQueryInstances() as $instance) {}

I suspect this is something suggested by PHPStan? I can see where it comes from in the Server implementation. That implementation uses PHP's "convert NULL to empty array on array access" side-effect.

I think the better (and more ergonomic for callers) fix would be to add $this-> persisted_query_instances = [];, right after the is_null if statement's closing bracked at the top of the function. That has a few positive effects:

1. The function never returns NULL so calling it is easier (because I'm only dealing with arrays)
2. If there are no plugins defined then we don't search for them every time getPersistedQueryInstances is called (which happens now, because in the no-plugin case, $this->persisted_query_instances is still NULL when the function is called after the first time).

For clarity we should probably just split that change out into a separate PR since it's not necessarily related to APQ? Then this PR doesn't need to be blocked by that change either :)