Views' config schema should not consider fallback plugin IDs as valid

Blocker is in.

Okay, I got the ball rolling here by fixing (I think) nearly all of the kernel tests. Functional tests are probably still going to fail. But I think what I have already got is a good start for someone else to pick up.

All green.

1. Skip validation on an intentional broken view.
2. Fix multiple views where plugins were not existing.
3. Adjust one test which seemed reasonable to have that as output. Think that is no BC

Think this is good to go.

Searched for allowFallback: true in views and all 6 instances appear to be addressed.

Assuming if any views were missed they would of got picked up, so assuming this is good to go

Skimmed through this and there are no questions unanswered. Rather straightforward actually.

Saving reviewer credit.

Cry havoc, and... grep!

[ayrton:drupal | Sun 12:29:25] $ ca https://git.drupalcode.org/project/drupal/-/merge_requests/6526.diff
# ...much composer and yarn...
[ayrton:drupal | Sun 12:31:09] $ grep -r "allowFallback: true" * | grep "yml" | grep -v "vendor" | grep -v "node_modules"
core/config/schema/core.data_types.schema.yml:          allowFallback: true
core/modules/block/config/schema/block.schema.yml:          allowFallback: true

Those are both not-Views-data schemata, so I think the scope is complete.

Regarding @smustgrave's remarks:

Assuming if any views were missed they would of got picked up, so assuming this is good to go

Given #12, the only possibility is now that there are invalid views that also have no test coverage whatsoever. I'll have a think for a few minutes as to whether there is an easy way to look for that. It's worth considering since we would be replacing a soft data integrity problem with a hard data integrity problem when we make this change in Views.

Also, this change is disruptive. While we're fixing all the core views, contrib and custom ones might be relying on this fallback too. So this needs at least a CR and maybe a release note. And... maybe even more. I bet loads of broken views are kicking around in sites and repos. I think, in fact, than an upgrade path of some flavor may be needed, or some deprecation-y thing.

What exactly happens if you have an invalid view and the schema support for the fallback is removed? The before versus after.

At the outside, we might want to split this MR into one that has the changes to all the views but that doesn't change the core schema, and put the schema change in a separate issue with an upgrade path and BC and whatnot.

Tagging for RM review since this is potentially disruptive fun time and we'll want to review the specific mitigations before it goes in.

Thanks everyone!

BTW, I haven't specifically asked in the RM channel about this issue yet, because it would be helpful to have other contributors' knowledge and ideas documented on issue first about:

Also, this change is disruptive. While we're fixing all the core views, contrib and custom ones might be relying on this fallback too. So this needs at least a CR and maybe a release note. And... maybe even more. I bet loads of broken views are kicking around in sites and repos. I think, in fact, than an upgrade path of some flavor may be needed, or some deprecation-y thing.

What exactly happens if you have an invalid view and the schema support for the fallback is removed? The before versus after.

At the outside, we might want to split this MR into one that has the changes to all the views but that doesn't change the core schema, and put the schema changes in a separate issue with an upgrade path and BC and whatnot.

Thanks!