PoC: Introduce provider support, access checker and token issuer

What does this MR do and why?

This is part of a PoC for Support new Self-Hosted Models Monetization with Provider-Based Access Control.

This MR introduces a new provider system to the GitLab Cloud Connector architecture, enabling more flexible and granular management of AI services and their associated add-ons.

Core Changes

• New Provider Model: Introduces Provider as a first-class entity in the data model alongside existing AddOn, UnitPrimitive, and other models
• Provider-AddOn Relationships: Establishes many-to-many relationships between providers and add-ons
• Enhanced Access Control: Updates AccessChecker to support provider-specific access validation
• JWT Token Enhancement: Adds provider information to JWT tokens for improved authorization

New Provider Configurations

• amazon_q - Amazon Q integration for GitLab Duo
• gitlab_duo - Core GitLab Duo AI features
• platform - Non-AI provider for cloud-connected services
• self_hosted_models - Self-hosted model deployment support

Schema Updates

• Add-On Schema: Now requires providers field as mandatory
• New Provider Schema: Comprehensive schema for provider configuration with fields for documentation, feature categories, groups, and lifecycle management
• Unit Primitive Schema: Enhanced to support provider associations
• Provider-Specific Add-On Support: Add-ons can now specify which providers they support, enabling granular provider-add-on relationships

Access Control Improvements

• Provider-Aware Access Checking: AccessChecker now considers provider-specific add-on requirements
• Enhanced Result Structure: Access check results include provider context and matching add-ons
• Flexible Add-On Matching: Supports filtering add-ons based on provider compatibility
• Provider-Specific Add-On Requirements: Different providers can have different add-on requirements for the same unit primitive

Provider-Specific Add-On Logic

This MR introduces sophisticated provider-specific add-on requirements that enable fine-grained access control:

Example: duo_chat Unit Primitive

• Available for: Both gitlab_duo and self_hosted_models providers
• Provider-specific requirements:
  • gitlab_duo provider: Works with duo_core, duo_pro, or duo_enterprise add-ons
  • self_hosted_models provider:
    • Only works with duo_pro or duo_enterprise add-ons (excludes duo_core)
    • Additionally requires customers to have either duo_enterprise or self_hosted add-on for the provider itself

Key Benefits:

• Same unit primitive can have different add-on requirements per provider
• Providers can enforce their own licensing and access restrictions
• Enables tiered access control where premium providers require premium add-ons
• Supports complex business logic for different deployment models (cloud vs self-hosted)

Technical Details

New AccessChecker Class

This MR introduces a completely new AccessChecker class that implements comprehensive access validation logic:

class AccessChecker
  def initialize(target:, active_add_on_names:, subscription_plan:, gitlab_version: nil, provider_name: nil)
    @target = target
    @active_add_on_names = active_add_on_names || []
    @subscription_plan = subscription_plan
    @gitlab_version = gitlab_version
    @provider_name = provider_name
  end

  def check
    # Multi-layered validation process
    unless has_supported_gitlab_version?
      return result(false, :unsupported_gitlab_version)
    end

    unless has_supported_subscription_plan?
      return result(false, :unsupported_license_plan)
    end

    if @target.requires_add_on? && matching_add_ons.empty?
      return result(false, :missing_required_add_on)
    end

    result(true, nil, matching_add_ons)
  end
end

Comprehensive Access Validation:

1. GitLab Version Compatibility:

   • Checks minimum GitLab version requirements
   • Supports different version requirements for free vs paid access
   • Considers provider-specific version requirements

2. Subscription Plan Validation:

   • Validates customer's subscription plan against target license types
   • Supports multiple license types per target
   • Ensures proper licensing for premium features

3. Provider-Aware Add-On Matching:

   • Matches customer's active add-ons against provider-specific requirements
   • Filters add-ons based on provider compatibility
   • Supports complex add-on relationships and dependencies

4. Multi-Level Access Control:

   • Provider-level: Checks if customer has required add-ons for the provider itself
   • Unit primitive-level: Validates add-on requirements for specific functionality
   • Combined validation: Ensures both levels are satisfied simultaneously

AccessChecker Result Structure:

AccessCheckerResult = Struct.new(
  :allowed?, 
  :scope, 
  :denied_reason, 
  :matching_add_ons, 
  keyword_init: true
)

Real-world example:

• Customer wants to use duo_chat with self_hosted_models provider
• GitLab Version: ✅ Meets minimum version requirement
• Subscription Plan: ✅ Has Enterprise license
• Provider Access: ✅ Has duo_enterprise add-on (required for self_hosted_models)
• Unit Primitive Access: ✅ duo_enterprise is compatible with duo_chat for this provider
• Result: Access granted with matching_add_ons: ['duo_enterprise']

Association Enhancements

• Added has_many association support for inverse relationships
• Updated existing models to include provider associations
• Improved association loading and caching mechanisms

JWT Token Updates

• Added providers field to JWT claims