[META] Ensure the Configuration and ConfigEntity systems fully support Views CRUD and status operations

Configuration system data types

There are multiple places configuration data may be found:

1. Module-provided defaults: Any module may provide default configurations in its config/install directory. These configurations are imported to the active configuration upon installation. A module may provide either:

   • Configuration in its own namespace (e.g., its default settings and configurations for its own functionality).
   • Configuration in another module's namespace (e.g., a default view of nodes provided by node.module).

2. Active configuration: The active configuration is the location of the current, canonical configuration for a given site. This includes both settings and stored ConfigEntity objects like views.

3. Staging: The configuration staging directory is used for deploying new configurations on a site. Configuration files in this directory are compared to the active configuration and imported or synchronized.

4. (Proposed) Snapshots: See #1515312: Add snapshots of last loaded config for tracking whether config has changed. The proposed snapshot directory creates a config snapshot following a successful import.

Views functionality

There are a number of operations users might wish to perform on a view:

1. Add a new view:
   • Through the UI.
   • From a module default.
   • From imported/staged configuration.
2. Update an existing view:
   • Through the UI.
   • From a version update to an already-installed module.
   • From imported/staged configuration.
3. Enable or disable an existing view:
   • During module installation or update.
   • Through the UI.
   • As part of a staging operation.
4. Revert an existing view:
   • To the state provided in a module default.
   • To the saved state before recent changes when editing in the UI.
   • To an earlier revision.
   • As part of the synchronization workflow.
5. List all views, their metadata, their original source/owner, and their active status.
6. Stage and manage changes or updates through the UI.
7. Locate and/or download a copy of the active configuration through the UI
   • For staging on restrictive hosting environments or in certain staging workflows.
   • For debugging or troubleshooting.

Relevant issues

• #1515312: Add snapshots of last loaded config for tracking whether config has changed
• #1601168: Orphan/obsolete keys and sub-keys *within* configuration objects are retained *forever*
• #1776830: [META-1] Installation and uninstallation of configuration provided by a module that belongs to another module's API
• #1398040: Detect if default configuration of a module has been changed, and allow to restore to the original
• #1620140: Allow synchronizing config entities from default config when modules are updated
• #1874394: Provide an API for upgrading configuration
• #1703168: [Meta] Ensure that configuration system functionality matches expected workflows for users and devs
• #1790398: Re introduce revert functionality for views using the config system
• #1825896: Add module owner to plugin data on handlers
• #1822048: Introduce a generic fallback plugin mechanism
• #1497268: Add revert functionality to Config entities
• #1826602: Allow all configuration entities to be enabled/disabled
• #1642062: Add TempStore for persistent, limited-term storage of non-cache data
• #1697256: Create a UI for importing new configuration
• #1760284: Rewrite ViewListController to use the core EntityListController
• #1781372: Add an API for listing (configuration) entities
• #1828414: Allow Views to be deleted
• #1969698: ConfigEntity::save() should disallow saving ID/UUID conflicts (Field UUID changes can badly corrupt field data)