feat chaotic-openapi: Bearer auth support (mirrors digest-auth handling)

Summary

Add reusable Bearer authentication support to chaotic-openapi, similar to the HTTP Digest security support from db10300.

The main goal is to avoid writing the same Bearer authentication boilerplate in every service and provide a common API that can be used with any JWT/token implementation.

Motivation

Currently, when a service uses Bearer authentication with chaotic-openapi, some additional bolt-on code has to be written around the generated clients/handlers.

This leads to the same code being copied between services.

Since chaotic-openapi already has reusable support for HTTP Digest authentication, it would be useful to have the same for Bearer authentication.

Goals

• Add support for OpenAPI HTTP Bearer security schemes:

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

• Support the existing OpenAPI bearerFormat: str | None field.
• Use bearerFormat as information about the expected token format, without coupling the implementation to a specific library.
• Remove service-specific boilerplate for Bearer authentication.
• Make generated chaotic-openapi clients handle Bearer authentication automatically.
• Provide reusable Bearer authentication support for generated handlers.
• Provide a common API for token/JWT verification that can be implemented using any library.
• Keep the actual JWT/token verification implementation outside of userver core.
• Allow applications to use any JWT library or custom token verification implementation.
• Integrate with config.chaotic.yaml / secdist where applicable, following the existing Digest approach.

Non-Goals

• Write JWT verification in userver core. The JWT library should be pluggable, meaning that it should work with any implementation.
• Make jwt-cpp a mandatory dependency.
• Make any particular JWT library a dependency of chaotic-openapi or userver core.
• Require PostgreSQL or any other specific storage/backend for token verification.
• Implement application-specific authorization logic.

Expected API

The important part is to provide an API/abstraction for Bearer token authentication rather than implementing JWT verification inside userver.

For example, an application should be able to connect its preferred implementation:

chaotic-openapi
      |
      v
Bearer token
      |
      v
userver Bearer/JWT authentication API
      |
      v
application-provided implementation
      |
      +-- jwt-cpp
      +-- another JWT library
      +-- custom JWT implementation
      +-- opaque token validation

The exact API can be designed during implementation, but it should not require userver to know which JWT library is being used.

bearerFormat

OpenAPI defines bearerFormat as an optional string describing the format of the Bearer token.

For example:

bearerAuth:
  type: http
  scheme: bearer
  bearerFormat: JWT

chaotic-openapi should take this field into account and make it available to the generated authentication integration where appropriate.

bearerFormat: JWT should not imply that userver must provide JWT verification or use a particular JWT library. It only describes the expected token format.

Acceptance Criteria

• chaotic-openapi recognizes HTTP Bearer security schemes.
• bearerFormat is supported.
• Generated clients can automatically add the Authorization: Bearer <token> header.
• Generated handlers have reusable Bearer authentication support.
• A public API/abstraction exists for plugging in token/JWT verification.
• The API can be implemented using any JWT library or a custom implementation.
• jwt-cpp is not required.
• No specific JWT library is introduced as a mandatory userver dependency.
• Configuration/secdist integration is provided where applicable.
• Existing Digest authentication support is not affected.
• Tests are added for Bearer security.