Resolve "Log headers from HTTP Router"

What does this MR do and why?

Context

With gitlab-org/cells/http-router!190 (merged), we added 2 headers to the request issued by HTTP Router, which then travels onto the Rails app.

The 2 headers are:

• X-GitLab-HTTP-Router-Rule-Action
• X-GitLab-HTTP-Router-Rule-Type

In the Rails app, we now have the need to log these headers for monitoring purposes, so that we know what % of requests are hitting the Rails app based on a certain rule matched by the HTTP Router. This MR accomplishes the logging of these 2 headers.

Execution

• we have a module named HttpRouterRuleContext, which obtains the values of the headers from the request object and creates a hash out of these values.
• this hash is then used in the base controller and API layer to inject the values into Gitlab::ApplicationContext
• once Gitlab::ApplicationContext has these (non-null) values, it gets logged.

Currently, we are logging these details for every single request that's coming into the controller layer, API layer and the internal API layer.

And since these values are only available within the request layer, these values naturally do not get logged in the non-web layer, for example: Sidekiq layer.

Screenshots

Controller logs (tail -f log/development_json.log)	API log (tail -f log/api_json.log)	Internal API log (tail -f log/api_json.log)

FAQ

• What happens if the HTTP Router isn't part of the Gitlab deployment yet? (like on gitlab.com)

  • This does not cause a problem. ApplicationContext does not log nil values, and hence the 2 keys (meta.http_router_rule_action & meta.http_router_rule_type) won't be present in the logs at all.

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.

How to set up and validate locally

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

Related to #474268 (closed)