Pipeline Graph Structural Update: Polling and GraphQL

The Problem

We are moving the big pipeline graph (and eventually the pipeline table and mini-graph) to GraphQL (see: #276949 (closed)). We need to determine and implement the correct way to harness the current Rails-middleware-etags-based long polling and caching from GraphQL + Apollo polling.

This is a blocker for rolling out the work in #276949 (closed).

Proposal

When performing a request against our GraphQL API endpoint include following HTTP headers:

X-GITLAB-GRAPHQL-FEATURE-CORRELATION: "verify/ci/pipeline-graph"
X-GITLAB-GRAPHQL-RESOURCE-ETAG: "pipeline/id/123"

This should allow us to write a GraphQL router for etags, something similar to our RESTful etags router, and using it in the Rack etags middleware.

The matcher should be implemented in a separate class and tested with unit tests. When GitLab detects that there has been no change in the resource since the previous request it will respond with 304 "not modified".