JWT Auth: Extract Pub/Sub Rules from Claims + Minor Fixes and Improvements

[ShvaykaD]

Pull Request description

This PR acts as an extension to the original PR: #232

It introduces support for extracting publish/subscribe authorization rules directly from JWT claims defined in the JwtMqttAuthProviderConfiguration. This enables more dynamic and flexible topic-level access control for MQTT clients in token-based authentication setups.

Use case:

The configuration now supports two optional fields: pubAuthRuleClaim and subAuthRuleClaim. When set, the broker attempts to extract corresponding lists of topic filter patterns from the specified JWT claims. These patterns are then compiled and applied as authorization rules for the MQTT client. If the claims are missing, malformed, or cannot be parsed into valid regex patterns, the system gracefully falls back to the default authRules configuration.

The fallback behavior is robust and isolated per direction: for example, if only pubAuthRuleClaim is specified, subscribe rules will continue to use the static defaults. If both are unspecified, the validator bypasses dynamic extraction entirely.

Additional Fixes and Improvements

Includes a SQL upgrade script to rename SSL to X_509 in the credentials_type column of the mqtt_client_credentials table. See commits: 48c928e 5aafe25

Removed duplicate configuration fields from the JWT authentication provider configuration to simplify the structure and avoid redundancy. See commit: 603ec02

Tests

This PR adds unit tests to verify the existing validation logic for JWT authentication provider configurations. These tests ensure that required fields are correctly checked and appropriate errors are raised for misconfigurations, making the system more robust and easier to maintain.

General checklist

• You have reviewed the guidelines document.
• Labels that classify your pull request have been added.
• The milestone is specified and corresponds to fix version.
• Description references specific issue.
• Description contains human-readable scope of changes.
• Description contains brief notes about what needs to be added to the documentation.
• No merge conflicts, commented blocks of code, code formatting issues.
• Changes are backward compatible or upgrade script is provided.

Front-End feature checklist

• Screenshots with affected component(s) are added. The best option is to provide 2 screens: before and after changes;
• If you change the widget or other API, ensure it is backward-compatible or upgrade script is present.

Back-End feature checklist

• Added corresponding unit and/or integration test(s). Provide written explanation in the PR description if you have failed to add tests.
• If new dependency was added: the dependency tree is checked for conflicts.

[dmytro-landiak]

Take a look at the last commit. Maybe you can find even better names for the added fields.
LGTM.
Waiting for UI