[PP-1] In most situations, config that references plugins should not be allowed to reference fallback plugin IDs

Created on 9 January 2024, 11 months ago

Problem/Motivation

This was discovered while working on #3332593-33: Adopt PluginExists validator in relevant places → :

Fallback plugin IDs are problematic from a config validation perspective. In general, I think fallback plugin IDs are meant to deal with unexpected missing plugin definitions at runtime. But by that same token, valid config should (almost) never contain invalid plugin IDs, and [PluginExistsConstraintValidator] should not, by default, accept a fallback plugin ID as valid.

There are a couple of cases where that makes sense -- for example, block entities, which might reference a block_content:$UUID plugin that doesn't exist yet -- but generally it doesn't. Core is littered with test views (and indeed, a couple of "real" ones) that contain invalid plugin IDs. Rather than fix them here, I decided to allow the PluginExists constraint validator to accept fallback plugin IDs in certain situations. We'll need a follow-up to fix all of those places and make the config schema stricter (by removing most of the allowFallback: true lines).

This is that follow-up.

Proposed resolution

Remove allowFallback: true from most parts of config schema, except in places where it makes sense. Tests will likely break due to this change, so adjust broken tests to fit the new expectations.