Fix named schema elements missing when installing Drupal

Found the reason for all the 'array' items. It was entity menu settings :D

Now down to these for INSTALLATION. There are likely a lot more AFTER installation, but we can put in something to test once Drupal can at least install :D

action.configuration.node_delete_action
action.configuration.node_make_unsticky_action
search.plugin.user_search <<< solved in #2266501: Array level schema errors are not reported, fix wrong schemas identified
views.filter_value.language
field.image.value <<< solved in #2266501: Array level schema errors are not reported, fix wrong schemas identified
field.image.value <<< solved in #2266501: Array level schema errors are not reported, fix wrong schemas identified
field.comment.settings
field.comment.value
field.comment.instance_settings
update.settings

The node actions were a bit confused too. There was an unsticky one but not as make_unsticky (even though make_sticky is there). Also the unpublish was not close to publish and the save had wrong cased label.

Should be down to the following:

views.filter_value.language
field.comment.settings
field.comment.value
field.comment.instance_settings
update.settings

#2266501: Array level schema errors are not reported, fix wrong schemas identified was comitted, this would not apply anymore.

While the patch technically applied, the field.image.value schema was duplicate, it was already added in #2266501: Array level schema errors are not reported, fix wrong schemas identified. I don't think there are other overlaps.

Yeah with this patch, indeed the following two things still appear as falling back to default:

views.filter_value.language
update.settings

Would be good to figure out why update.settings appears and see if we can do something about disabled modules vs. schema. One option is we parse in all the disabled module schemas, but that would not help for modules that include optional views components from modules that may or may not be enabled... Also not sure how it would affect performance just so we have some coverage for the minority case... However this questions that we can throw exceptions wholesale when parts of schemas are missing, which makes it hard/impossible to ensure that core has full schema coverage unless we can identify a small set of keys that are problematic and stick to that.

Updated #2183983: Find hidden configuration schema issues with info following @catch's concerns in #2264179: Clarify use of property/undefined and add an ignore type in configuration schema. I'm not sure we can solve the throwing of exception here, but we can try :)

All right, this is the only patch we have that fixes existing schemas now :) How do we add tests to prove this is good? :)

Thanks @alexpott for identifying the module enable combined with a stale config factory in the install config form caused update.settings to pop up. By resetting the config factory in there, that is resolved. So now only the known views exception remains. Let's see all the rest of the fails now with that exception...

Rerolled to apply. No changes.

That is an impressive set. Looks like the good news is these are mostly things we knew:

- migrate.* which is the overwhelming majority will be resolved with #2183957: Provide configuration schema for Migration module.
- language.config.* which is also a *lot* will be resolved with #2224887: Language configuration overrides should have their own storage
- then there are only test ones left which we said we don't want to cover
- content_translation.settings pops up a lot which was supposed to be fixed by #2224761: Add a generic way to add third party configuration on configuration entities and implement for field configuration but that got on a totally different track
- finally action.settings pops up some which is puzzling, that has a schema... may be similar to the installer use case of update.settings where the module is enabled and then config directly fiddled with

I did not look at all the fails but this seems to be covering most. So seems like no new ones uncovered, which is surprising based on my pessimistic expectation but definitely good news :D We should work on getting in the above to cut down on the fail counts here.

Looks like however we cannot add the exception for various reasons, mainly we want to keep schema optional for tests and contrib, so we cannot fail on the type fallback, it needs to just work. So we can use this technique to manually find missing core types but not as a part of the final system.

I think the fixes proposed in this issue can be proven by adding the exception and showing the installer would fail. So a with fixes and test only version would work for that IMHO. Here is a test only patch. Should hopefully fail on install.

So then the fixes only, given the test only one proves Drupal would not install without the fixes and #6 proved the fixes worked.

Yay, thanks!