Integrate az_secrets with az_person_profiles_import module

[trackleft]

Motivation

The az_person_profiles_import module currently stores UA Profiles API credentials in configuration, which gets exported to code repositories. The az_eds module recently received secrets management integration via PR #4373, and az_person_profiles_import should have similar functionality for consistency and improved security practices.

Is your feature request related to a problem? Please describe.

Currently, the UA Profiles API endpoint and authentication key are stored in the az_person_profiles_import.settings configuration object. When configuration is exported, these credentials are written to version control, which is a security concern. Additionally, changing these values between environments (local development, staging, production) requires manual configuration imports or settings form updates.

Proposed Resolution

Describe the solution you'd like

Integrate the az_secrets module with az_person_profiles_import following the same pattern established in PR #4373 for az_eds:

1. Add SecretsChecker service to az_secrets module for checking if Key entities exist and have values:
   • Methods: hasKey($key_id), hasKeys(array $key_ids), getKeyValue($key_id)
   • This service provides a reusable way to check for secret availability without directly checking config values (which don't get populated when using Key module overrides)
2. Create optional Key configuration entities for:
   • key.key.az_profiles_api_endpoint (maps to AZ_PROFILES_API_ENDPOINT env var/Pantheon secret)
   • key.key.az_profiles_api_key (maps to AZ_PROFILES_API_KEY env var/Pantheon secret)
   • Config override entities to map these keys to the configuration values
3. Modify AZPersonProfilesImportSettingsForm to:
   • Inject and use SecretsChecker service
   • Detect when secrets are configured
   • Display status message indicating credentials are managed by secrets
   • Disable endpoint/key fields when secrets are active
   • Skip saving to config when secrets are in use
4. Modify AZPersonProfilesImportForm to check for secrets via SecretsChecker when determining if API key is configured
5. Modify AZProfilesAPIFetcher data fetcher plugin to:
   • Inject SecretsChecker service
   • Use secret values when available, falling back to config values
   • Fix constructor to properly pass all required arguments to parent Http class
6. Refactor existing secret consumers (az_eds module) to use the new SecretsChecker service for consistency

This allows credentials to be managed via environment variables (local/Lando) or Pantheon Secrets (production) without exposing them in version control.

Roles and Permissions considerations

• Anonymous user: No impact
• Authenticated user: No impact
• Content editor: No impact (cannot access settings forms)
• Content administrator: No direct impact, though they would see the status message on settings forms if they have permission to access them
• Administrator: Benefits from improved security and easier credential management across environments. Settings forms show clear indication when secrets are active and prevent accidental overrides.