Harden access-key authentication for Cache Utility HTTP API

Problem/Motivation

Cache Utility provides HTTP API routes protected by a configured access key. Authentication and rejection handling should be centralized and strengthened so that all API controllers apply the same security requirements.

This was originally reported as a private security issue but was approved for handling in the public issue queue by the Drupal Security Team.

Background information

• Confidential private issue:
  https://git.drupalcode.org/security/185476-cache_utility-security/-/work_items/1
  (included for reference; users without access may receive an access-denied response).

Detailed reproduction information has intentionally not been copied from the confidential issue.

Proposed resolution

• Introduce a shared authentication service for all Cache Utility HTTP API controllers.
• Use exact, timing-safe access-key verification.
• Return consistent, non-cacheable authentication-denial responses.
• Rate-limit repeated failed authentication attempts.
• Generate cryptographically secure access keys for new installations.
• Validate new or changed access keys while preserving existing integrations until administrators rotate legacy keys.
• Add automated unit and functional test coverage.

Remaining tasks

• Review and sanitize the existing patch and tests for public disclosure.
• Run the unit and functional test suites.
• Create a public issue fork and merge request.
• Manually verify authentication, throttling, and access-key configuration.
• Prepare release notes after the change is reviewed and accepted.

User interface changes

• Add a cryptographically secure access-key generator to the Cache Utility settings form.
• Validate new or changed access keys.
• Display a warning when an existing access key does not meet the current recommendations.

API changes

• The existing CU-ACCESS-KEY request header remains in use.
• Successful authenticated requests retain their existing behavior.
• Missing or invalid credentials receive a generic HTTP 403 response.
• Repeated failed authentication attempts may receive HTTP 429 with a Retry-After header.
• Authentication-denial responses are marked private and non-cacheable.

Data model changes

No database schema changes are required. Configuration schema definitions are added for the authentication settings.