Introduce Prometheus metrics for collecting HTTP Router metrics

What does this MR do and why?

This MR accomplishes the final ask of #474268 (closed)

[ ] increment a counter of that metrics X-GitLab-HTTP-Router-Rule-Action & X-GitLab-HTTP-Router-Rule-Type when present.

These headers are set by the HTTP Router component (introduced in gitlab-org/cells/http-router!190 (merged)), which then flows into the Rails app.

In the Rails app, it is now essential to monitor these headers. For this, we already log these headers (introduced in !162543 (merged)), and we now we need to increment Prometheus counter metrics when these headers are present, which is what this MR accomplishes.

The metrics look like this on /-/metrics after this change:

# HELP gitlab_http_router_rule_total Multiprocess metric
# TYPE gitlab_http_router_rule_total counter
gitlab_http_router_rule_total{rule_action="classify",rule_type="FIRST_CELL"} 5
gitlab_http_router_rule_total{rule_action="proxy",rule_type=""} 2

As of today, the following cardinalities are possible:

• HTTP Router directly proxies the request to a given address of a cell, and hence action=proxy, with a NULL/empty type.
• HTTP Router classifies the request to send it to the first cell, and hence action=classify, with type=FIRST_CELL.

These metrics are being incremented on ALL requests hitting the controllers and the API layer.

On gitlab.com, HTTP Router isn't set up yet, so this MR will essentially be a no-op on gitlab.com today. When HTTP Router is deployed later, these metrics will start registering.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Related to #474268 (closed)