Move Providers from being tied to Features to being global

[dkotter]

Description of the Change

At the moment, the workflow in ClassifAI is to go into a Feature, choose the Provider you want for that Feature and enter in any Provider credentials from within that Feature. There's nothing wrong with this approach but it does require you to enter your credentials again for each Feature that you want to use the same Provider for (which is likely the majority of use cases).

This has been a common request (to simplify how Providers are setup) and we've also gotten quite a few recent requests around making it easier to programmatically manage credentials (for instance, setting those up as constants in wp-config.php instead of having to enter those in the UI and have those saved to your database).

This PR attempts to address both of these by introducing the concept of global Providers, while still retaining the ability to override credentials at the Feature-level if desired (and to help maintain backwards-compat).

At a high-level, this is what has been done:

• Introduce a new Providers settings tab that renders out all Providers with their required credential fields
• Refactor the components that render these credentials so they can be used both on this new global Providers page and within the individual Features
• Introduce new classes that help manage Provider profiles and configs, as well as a central place to verify credentials
• Introduce a new CredentialResolver class that will determine where to pull credentials from (either the global scope or the Feature-scope)
• Add new methods on the Provider class that get all credentials for that Provider or a specific credential field. These all pass through a new filter (classifai_provider_credentials) making it easy for other to hook in and change those credentials
• At the Feature-level, add a new Override toggle that allows you to use Feature-level Provider credentials. For new installs, this defaults to being off and thus all Features by default will use global credentials. For existing installs, all Features are considered to be overridden and will use the existing Feature-level credentials, though we show prompts in these situations so users can migrate to global credentials if they desire
• Remove the unneeded Credential Reuse code as we aren't sharing credentials anymore
• More standardization on how API requests are made, making it easier to ensure all credentials pass through our new filter and setting us up for the future where we will integrate the new WP AI Client for these requests
• General refactoring / code cleanup to account for this new architecture. I tried to keep this to a minimum as this PR is already quite large but some of this was necessary and some felt like the right thing /right time to do

Screenshots

How to test the Change

This is a fairly global change and as such, testing multiple Feature / Provider combinations is the ideal. In addition, testing Features with overridden credentials and Features with global credentials is ideal.

Changelog Entry

Added - Ability to set Providers at a global level, allowing you to easily re-use Provider credentials across all Features that need them
Added - New setting that allows you to override Provider credentials at the Feature-level. For any existing sites that have set up ClassifAI, your Features will be considered to be in an override state but you can migrate credentials to the new global scope as desired
Added - New filter, classifai_provider_credentials, that allows developers the ability to override AI credentials prior to those being used
Changed - For filters that run when API requests are made, the Feature name, not the Feature option name is now passed as an argument. If you have code that relies on that argument, updates will be needed
Removed - Credential re-use code has been removed as it is no longer needed

Credits

Props @dkotter, @fabiankaegy

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added Critical Flows, Test Cases, and/or End-to-End Tests to cover my change.
• All new and existing tests pass.

[peterwilsoncc]

I'm doing some manual testing prior to the code review.

1. Once the feature is merged, instead of prompting users to add feature level credentials to the providers tab, I think it would be better to either:

• provide a link "migrate these credentials to global providers"
• be opinionated and automatically migrate the credentials if the same credentials are been used in all the features

2. Prior to the provider credentials being configured, it's possible to toggle the "override provider credentials" checkbox off and save. Using the title generation as an example, toggling the checkbox off then results in a "A valid URL was not provided." error in the editor.

3. For feature level settings that match the global settings, I am wondering if the best approach is to remove the feature settings for the migration. We'd need to store an option indicating the migration has taken place so if the same settings are added we don't auto-migrate again.

[dkotter]

Note pausing on this temporarily and will be pulling out some individual pieces here to get those out quicker (first is done, #1043)