Add instrumentation for ETag cache hits (log 304, 429 responses)

What does this MR do?

Original Issue: #26941 (closed)

This MR adds instrumentation for ETag Cache hits. This middleware short-circuits Lograge, hence Lograge does not pick up these 304 or 429 responses.

Here, we inject an invent once cache has been hit.

Ideally, ActiveSupport::Notifications.instrument... would be called with a block where the request takes place, but since we arrive as a conclusion to respond with 304 over multiple if-then-else blocks, it seems better to send out the notification after the response has been decided.

We want the logging format to be as close to a response log format as possibly, e.g. Completed 304..., so we send the same event as sent out from controllers.

The controller and action are not known at this point of execution, so we set them both as unknown. The path can still be used to determine which requests hit cache most.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• [-] Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team