Security: Introduce the Secrets API.
Credentials such as API keys and tokens are usually stored as plaintext options, so anyone with a database dump or backup can read them. The Secrets API gives plugins and core a place to store them encrypted instead, using wp_set_secret(), wp_get_secret(), wp_delete_secret() and related functions. Each secret keeps its previous version, so a credential can be rotated without breaking the code that reads it.
By default, secrets are encrypted with libsodium and stored in the options table. The encryption key never goes in the database: it comes from a WP_SECRETS_KEY constant in wp-config.php, or is derived from the LOGGED_IN_KEY and LOGGED_IN_SALT constants when that is not defined.
Hosts can use a different method by adding a wp-content/secrets.php drop-in, which loads just before must-use plugins, in the same way object-cache.php replaces the object cache. A drop-in can hand all storage to an external secrets manager, or replace only where secrets are stored or only where the encryption key comes from, such as a key management service. If a drop-in is broken, every Secrets API call returns a WP_Error rather than falling back to the default method, so a misconfigured host shows up as an error rather than as secrets that appear not to exist. Conformance test suites are included for drop-in authors.
Also adds the manage_secrets capability, granted to administrators through populate_roles_720() and upgrade_720(), the manage_network_secrets meta capability for super admins, and Site Health tests for the Secrets API.
This provides the encrypted storage requested in #64789, so the Connectors screen's API keys can move off plaintext options in a follow-up. The admin screen is deferred to 7.3, and the WP-CLI commands stay in the feature plugin.
Props ericmann, westonruter, mindctrl, audrasjb, whyisjake.
Fixes #66187. See #64789.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
