Fix missing schema for URI widget

You accidentally uploaded the patch for #2555259: Add config schema for image_convert image effect :)

Setting back to active, the patch is accidental. Also would needs tests as every other schema fix. Not sure why we broke this out of #2554151: Test content/configuration in update database dump, that one has failing tests due to this missing.

At minimum this is critical and blocking that issue.

We're also missing field schemas for quite some field types: #2462155: Field settings schema missing for some field types

+++ b/core/config/schema/core.data_types.schema.yml
@@ -491,7 +491,7 @@ field.value.string_long:
-  type: mapping
+  type: field.storage_settings.string
   label: 'URI settings'
   mapping:
     max_length:

In #2462155: Field settings schema missing for some field types, @stefan_r pointed out that the is_ascii option makes no sense on uri items. Instead of this., should we maybe remove that option from it instead of this? If we keep this, should remove the now duplicated schema definitions below?

+++ b/core/modules/field/src/Tests/Uri/UriFieldTest.php
@@ -0,0 +1,103 @@
+class UriFieldTest extends WebTestBase {
+
+  /**
+   * Modules to enable.
+   *
+   * @var array
+   */
+  public static $modules = ['entity_test', 'field_ui', 'options'];

Do we really need to make this a web tests with field_ui (and options module?) Those kind of tests usually extend from FieldUnitTestBase, see EmailItemTest for an example.

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/UriItem.php
@@ -32,9 +32,10 @@ class UriItem extends StringItem {
+    unset($storage_settings['is_ascii']);

Let's add a comment explaining URIs should not be ASCII so this setting is unavailable on the uri field type.

Also:
<berdir> yeah, my only point is that IMHO, the test should be named UriItemTest so it is consistent with other tests (*ItemTest being kernel tests while *FieldTest are testing the UI)

lgtm

Committed/pushed to 8.0.x, thanks!

The patch committed resulted in a state where the PHP does not use is_ascii while the config schema allows for it on URI settings. In such situations, instead of defining a key for an otherwise invalid setting combination, we introduced base types and inherited from each other from them. The result after this patch unfortunately allows for invalid data combinations, and will not figure out if for example migrate tries to use the is_ascii key on URI settings for something.

Opened #2558635: Config schema invalid for field.storage_settings.uri, allows for is_ascii key to resolve this. Depending on what kind of schema changes do we consider data model changes it may or may not be higher priority.

In more detail:

+++ b/core/config/schema/core.data_types.schema.yml
@@ -491,7 +491,7 @@ field.value.string_long:
 field.storage_settings.uri:
-  type: mapping
+  type: field.storage_settings.string

This is problematic because it adds all three keys of string, only 2 of which are allowed on uri. It also kept defining the 2 allowed here, which is pointless if already inherited. So its also a double-definition now. We either need to roll back this line or add a more sophisticated base type. See #2558635: Config schema invalid for field.storage_settings.uri, allows for is_ascii key.