Config schema mapping parsing is inconsistently forgiving, does not conform to the interface

First patch based on extract of what @reyero came up with earlier in #2277945: Typed configuration implements TypedDataInterface improperly but was descoped there. Not tested :D

#2293105: MigrateActionConfigSchemaTest duplicates all its code from SchemaCheckTestTrait removes/reworks the migrate test base as well in favour of needing to duplicate code.

Schema trait test fixed. Ran some more tests locally and those passed.

Note also (in interdiff) that this now also fixes inconsistent error reporting in the schema check as a nice side effect. Before, if a non-array type element was found, it said it is DEFINED as a non-array type but is an array. Now if it is not defined it will say schema missing (correct error) instead of saying how is it not well defined (incorrect error, since its not even defined).

Also needs tests for itself, that is basically that we can access non-defined mapping items through the schema.

All the fails are legit mismatches of schema vs. data structure, yay. Swallowing the exceptions before did hide these issues. Yayay. Includes the following fixes:

- LinkFieldTest.php used url_only wrong, as an array of booleans even though its a boolean; see that url_only is a single boolean checkbox in LinkFormatter
- system info schema mismatch in update_test, the settings are a sequence of sequences, not just one sequence, see update_test_system_info_alter()
- views access by role is a list of roles under a single container key named role, see the access/Role.php class in views

There are further fails that need fixing but this should fix a lot.

Woah, also looked at the field SQL fail. The problem is with the indexes schema. Unfortunately the indexes may be an array or a string. The schema says its a string, which is correct for SOME cases, but not all. Eg. FeedStorage.php has this snippet showing both:

    $schema['aggregator_feed']['indexes'] += array(
      'aggregator_feed__url'  => array(array('url', 255)),
      'aggregator_feed__queued' => array('queued'),
    );

There is no data we can inspect to figure out if its a mapping of 0: name (string), 1: length (integer) or a string. So we need to use the much dreaded ignore type here to be correct :/ (Or change the data structure, which I don't want to do here).

Still several ones to figure out. Its a hunt.

Fixing the contrib update test too. This one has a test module with a schema but needs the second fix in this issue :D The update_status config it has is not a sequence of strings but instead a sequence of mappings with module status information. Makes that one passing too.

I have a really hard time figuring out the filter/ck fails, all of which seems to come down to how allowed values are stored for HTML formats. I could not find the matching schemas at all to the data so far... If someone can help with that that would be great. I'll stop for today and pick it up tomorrow.

Rerolled following #2293105: MigrateActionConfigSchemaTest duplicates all its code from SchemaCheckTestTrait landed. No other changes.

Update fixing two more issues:

- ConfigEntityQueryTest was using the 'array' key in the config test entity as a two level array and it was not defined as such, now defined like that :)

- Drupal 6 field instance migrations migrated vocabulary and parent settings to field instances where they have no business to be... they should be on the field itself, where they already are; thanks @chx for helping me figure this one out

+1: I debugged and found the cause for the options field fail as well, but that is somewhat complicated :/ It is about float type fields with allowed values. For these, you have allowed values as follows on the UI:

0.5|Small value
1.5|Bigger value

This is stored in a sequence keyed by the float and the value casting uses the array keys to access elements. So this becomes settings.allowed_values.0.5 which is a BIG no-no, since it is understood by the config/schema system as two levels of elements under allowed_values, which is not the case. We need to figure out how to refer to those elements or figure out something else for the value casting, eg. get elements individually instead of their full dotted path. Will try to summon @alexpott for this unless I come up with something useful and reasonably easy myself...

With proper tag field setup in the migrate test.

So the CK and the FilterAPITest issue was that there is a test-only FilterTestRestrictTagsAndAttributes filter defined but no settings schema, so the default filter_settings.* schema applied which would be a sequence of strings. That does not apply to this mapping/array thing. Unfortunately there are settings here that cannot be described again with schema, they may be either array or bool. So used the ignore type again. Heh.

Thanks @WimLeers for helping me figure this one out. Added a suggested commit message now that there is so much external info on this :)

This should be down to the float (optionuitest) and exception (configcrudtest) fails.

Fixing the config crud test based on discussion with @alexpott. This is another existing bug in core that the new behaviour exposed :D Yeah. So if you tried to set an unsupported type to an existing element that had an undefined type (eg. type: bunny) then that would totally go through. An easy fix is to do the basic type validation even for undefined/ignore types, those should not be able to store resources and other wild types that are not arrays or scalars. This is ensures for other types in castValue() and validateValue(). Also improving docs on validateValue().

This should only leave the float option element which will need to reformulate how field allowed options are stored. Meh.

So the final one is the +1 problem explained in #18. Discussed that with @alexpott too, and since the format of the data stored is fundamentally going against config principles, the config data format itself needs fixing. Looking at the code for allowed_values this is a very far reaching change and changes fundamental parts of the field structure so may be beta blocking in its own right (but IMHO at least critical). So opened #2293773: Field allowed values use dots in key names - not allowed in config as a separate issue for it.

For this one the best we can do for now is we type it as ignore instead of a sequence, which will ignore the whole thing. This should be reworked in #2293773: Field allowed values use dots in key names - not allowed in config entirely, this is just a stop-gap. Especially because for it to be translatable, we NEED it to not be ignored. We need default option values to be translatable because they show up as UI labels.

Crosspost I think? Reuploading patch.

Now with test for what this does in itself. Makes items on mappings that are not defined be undefined instead of fail hard. The test only patch is the interdiff in one :)

This fixes bugs in migrations, views access with roles, link field testing, etc. so elevating to major.

Best person to final blessing would be alexpott :)

Yay, this now allows debugging of missing schema item definitions in config inspector immediately :)

Opened #2295737: Not all shipped configuration passes validation even with all modules enabled with the issues it finds in the standard schema.