Set feature category in metrics for ETag caching hits

What does this MR do?

When a request hits a Rails controller, we set the X-Gitlab-Feature-Category header to the feature category for that path, which we then use as a label in our Prometheus metrics.

For ETag caching hits, we weren't setting this, because those skip Rails entirely (that's the point of them!). This annotates the ETag caching routes with their feature category to set the same header there.

We don't need this for cache misses because they go to Rails anyway.

You can see this in production at https://thanos-query.ops.gitlab.net/graph?g0.range_input=1h&g0.max_source_resolution=0s&g0.expr=sum%20by%20(status)%20(irate(http_requests_total%7Benvironment%3D%22gprd%22%2C%20feature_category%3D%22unknown%22%2C%20type%3D%22web%22%7D%5B1m%5D))&g0.tab=0, because the vast majority are 304s. Locally, here's the impact of this change when viewing an issue page:

We can also see this with curl, because of the header. Before this change:

$ curl -si http://localhost:3000/flightjs/flight/-/issues/6/realtime_changes | grep -e '\(HTTP\|Feature-Category\)'
HTTP/1.1 200 OK
X-Gitlab-Feature-Category: issue_tracking
$ curl -siH 'If-None-Match: W/"70b8a796e80986b6910e5c50b35e568e"' http://localhost:3000/flightjs/flight/-/issues/6/realtime_changes | grep -e '\(HTTP\|Feature-Category\)'
HTTP/1.1 304 Not Modified

After:

$ curl -siH 'If-None-Match: W/"70b8a796e80986b6910e5c50b35e568e"' http://localhost:3000/flightjs/flight/-/issues/6/realtime_changes | grep -e '\(HTTP\|Feature-Category\)'
HTTP/1.1 304 Not Modified
X-Gitlab-Feature-Category: issue_tracking