Views tests don't pass strict schema checking

Fixes based on the fails:

- Somehow some test views still included bugos items. That questions if #2325269: Test and fix views in test_views directories against their configuration schema did really test all views.
- views.access.none has no options, should not pretend it has.
- there is a 'deleted' flag on displays that should be in the schemas (see core/modules/views_ui/src/Form/Ajax/ReorderDisplays.php and core/modules/views_ui/src/ViewEditForm.php)
- Views also has a views_exposed_filter_block block type, which extends from views blocks, need the same settings (took the chance to define a base views_block type that people can extend)
- In core/modules/views/src/Tests/Plugin/DisplayTest.php when adding new displays manually to the view, we need to at least specify a valid display plugin.
- Tests use views_test_data.tests and define an access plugin, 2 display plugins, a query plugin, a row plugin and a style plugin with test settings. These need schemas in the test module.
- CustomBooleanTest.php changes the field id to boolean but not the plugin_id, so the boolean related settings were invalid later in the test.

These should fix most of the fails. There are still other fails that are more interesting :) Especially display extenders are suspicious that the way they may alter views settings may not even be possible to explain with views schema! Hah.

The stakes are getting higher but the fails that still remain will be the real interesting ones :)

- BlockDependenciesTest.php has an outdated copy of drupalPlaceBlock() that put visibility settings in the wrong place in the config structure, that was still failing on views blocks; this is not based off of WebTestBase, so that is why we cannot use that as-is; also there is no actual use of visibility testing with views blocks but the empty array that crept in is enough to be a problem

- My fix in DisplayTest.php was wrong, the new displays should also be instances of 'display_test', not 'page', the test later on relies on being able to set the test setting on it.

- My fix to set the boolean plugin_id in CustomBooleanTest.php was not correct. We need to set it where we override it, this is not actually stored in views data.

- In QueryTest.php, althgough the views_data is modified with a different query plugin for this table, the view already has a query plugin assigned from earlier and views only uses that table based default for new displays. So we need to modify the value on the display since we are testing an existing display.

Duh rolled that one the same as 6. Now rolled with the actual changes from the 9 interdiff. No change to whaat 9 should have been.

@catch: Good find! So what ViewStorageTest does is the following:

    $displays = $view->get('display');
    $displays['default']['deleted'] = TRUE;
    $view->set('display', $displays);
    $view->set('id', $this->randomMachineName());
    $view->save();

Looking at the code flow, ViewEditForm::save() is the one that reacts on a 'deleted' value on display when saving, and when saving as pure config, that will not have any effect. View::save() just inherits fromConfigEntityBase::save(). I think this test code assumed it would change the view ID, so effectively saving a new view, so the deleted flag would be adhered to. But that only seems to be implemented in the form.

So we can remove the default display with the display handler and save it like that. Attached an attempt for that.

Also note that addDisplay() seems to be perfectly capable to overwrite the default display, if we want to add a default display it will not complain if there was already one. So technically we don't even need to delete the default display to ensure it is still position 0 although then we would only know if the new display was loaded back if we also assert the title. I added one assert for that for being extra sure.

Worked on fixing some of the things I thought I fixed already...

- ViewStorageTest.php: I did not find a reliable way to remove the default display that did not have side effects in this test, so I just documented we rely on the fact that it is set again; It is not possible to create views out of the box without a default display, that is added in creation.
- CustomBooleanTest.php: I have several unrelated unserialize() fails locally but the problem seems to be that whatever we set for the field, since the view itself has a plugin_id already, we need to update the view (not just the views data); so saving the view after doing the config update will hopefully work :) again cannot run this test locally
- in QueryTest.php I attempted to update displays with the simpler array syntax, that assumes the view is loaded as the config entity not as the executable (that getView() would return), so I used that for simpler test code.

@jibran: StorableConfigBase::castValue() validates the value for storage. Ie. if you try to store an int where a mapping should be, it will throw an exception. It does allow for holes in the schema (where the type is Undefined). Strict schema checking on the other hand will find all incompatibilities with schema *including* missing schema coverage. Tests currently use $strictConfigSchema = TRUE; which makes all config use strict checking or SchemaCheckTestTrait which requires some more manual integration in tests and is used for testing specific things. We are migrating all tests over to $strictConfigSchema = TRUE; and hope to reach a state where all tests pass with strict config schema :) We found **so many** major and critical bugs on the way.

@dawehner:

1/3 looks like the same code :) This test just copies WebTestBase::drupalPlaceBlock, so all I did was update the copy-pasted code. The exact code exists in WebTestBase.

2. addDisplay() does overwrite the default display when you try to add a default display, does not matter if there was or was not a default display before. So the result of the test is the same. Do you have a good suggestion for removing the default display reliably? $displays['default']['deleted'] = TRUE; was a no-op, it did not actually delete the display because that flag only has effect in the views *form* not the API. So it was already testing overwriting the default display I just removed code from the test that did not do anything else but set an invalid "deleted" key on the default display.

Further fixing:

- Found out that there is no reason to set the display plugin again on those test displays, those are already set.
- However, we can define the fake invalid display plugin for the sake of schemas (to inherit from page displays as they are used), so we don't get schema fails. The invalid display of course should not be defined in PHP that is the point of the test.

Helps if I don't make typos in the schema.

So we are down to the two most complicated fails here.

1. Display extenders are fundamentally incompatible with config (and therefore schema) assumptions. In config, the idea is every part of config has an owner that is somehow statically stored in the config as a dependency. The config entity shell itself is provided by views, but then all fields used will have a provider and therefore dependencies, etc. Display extenders are allowed to just alter the display with any additional keys in a non-identifiable way. It is not possible to tell if key X or Y is of the actual display_plugin or a display extender (by looking at the config). I think this needs a fundamental change, namely that display extenders would either be allowed to alter existing display settings or employ a ThirdPartySettingsTrait based solution where each 3rd party setting has clear ownership. I think that is a fundamental change and not sure this issue should also do that. We can exempt that test from strict schema checking for the scope here and open one more critical. Opinions?

2. When duplicating displays, what ViewEditForm::submitDuplicateDisplayAsType() does is it removes the display_title and display_plugin but otherwise clones ALL the settings of the display. That is ending up with all kinds of cruft in the new display setting, such as in the test a path for a block. Not good. So what I thought we can do there is to ask the display for their options and then filter the options from the old display with the possible options of the new. That is not possible because defineOptions() is protected on PluginBase and not intended as a public method. I previously also thought display extenders would be a problem here, but getting their stuff integrated is part of defineOptions() on DisplayPluginBase. The $view->options array is actually public, but sounds like it would be a major sin to use that directly, haha... #evilgabor

We can either choose to exempt these two tests from the strict checking in this issue and solve these in a separate issue or solve them all here. In the first case, we have even more issues, in the later we'll have wildly unrelated fixes combined. I am fine with either.

Thanks for opening those issues. Then all is left to do here is to exempt those two tests from the strict schema checking.

Also I think that removes the critical component of this one, so lowering to major.

Thanks all! Let's go to #2387149: Display extenders are not possible to describe with config schema and #2387157: Cloning display into another display also stores options that are not supported by the new display type now :)