Replace "required" flag of Field module with proper dependencies

@sun user picture is a field, so probably image also needed

FieldInfo is needed for FieldableDatabaseStorageController and only for fieldInfo->getBundleInstances()
So at least any fieldable entity require it to properly populate fields, probably related #2114707: Allow per-bundle overrides of field definitions

The goal is to replace field.module's FieldInfo with a registry of base + configurable fields handled by Core/Field in #2116363: Unified repository of field definitions (cache + API).

This will be a lot easier after #2167167: Remove field_info_*() ;)

Let's see what happens. A lot of field type modules like text already depend on field, so most dependencies should already be covered...

Stupid DependencyTest is stupid! ;)

No, user does not depend on field because the field.info service is gone. The integration of configurable fields into entity storage is 99% optional, field.module hooks into the relevant processes.

There are still a handful of references/dependencies on field.module in Drupal\Core\Field|Entity, see #2079427: Core/Entity depends on classes / functions from field.module, but they're going away, nothing blocking left.

There is one exception and I hit that when I tried to move the user roles table to a normal field table that is managed by the entity storage, see #2248977: Complete support for multi-value base fields in ContentEntitySchemaHandler and use it for the user.roles field. But that's just a stupid static method call that is already fixed in @plach's entity storage issue, see the issue above.

Testing by removing the required property + "drush si -y testing", works fine.

This makes perfect sense to me, but before RTBC lets see what testbot thinks there have been lots of commits.

today, locally I too can drush site install :)

Interesting, now we actually had test fails :)

Fixed two problems:

- WidgetBase called functions from field.module for that filter xss stuff. Moved those to WidgetBase for now as public static, they're also used from some formatters and views. Not sure if there's a better place for this? a helper class maybe? With this change, the contact tests, which are now using widgets, are verifying that you can do this for base fields and core field types, without field.module.

- content_translation_install() is updating field_storage_config entities, added a module exists check there as it would theoretically be possible to use it without field.module.

Forgot to update the calls to that method. Pretty sure that WidgeBase is not the right place now :)

Ouch - yeah, not sure where to put field_filter_xss_*(), and WidgetBase is not the right place. A FieldXss utility class ? :-/

As a side note, I didn't closely follow the autoescape / SafeMarkup thing, but the resulting code in field_filter_xss() is a bit weird :
#1825952: Turn on twig autoescape by default did :

  function field_filter_xss($string) {
-    return Html::normalize(Xss::filter($string, _field_filter_xss_allowed_tags()));
+  return SafeMarkup::set(Html::normalize(Xss::filter($string, _field_filter_xss_allowed_tags())));
  }

but Xss::filter() already calls SafeMarkup::set(), so we call it twice ?

Backtracking through history:
- D7 just does return filter_xss($string, _field_filter_xss_allowed_tags()) there.
- #1798654: Clean faulty HTML in help description of field widgets wrapped that in _filter_htmlcorrector()
- #2195745: Replace _filter_htmlcorrector() with a utility class in core replaced _filter_htmlcorrector(filter_xss()) with Html::normalize(Xss::filter())
- #1825952: Turn on twig autoescape by default wrapped the above in SafeMarkup::set(), but also made Xss::filter() itself call SafeMarkup::set()...

Pinging the folks in #1825952: Turn on twig autoescape by default.

Related #2309929: HTML double-escaping in field forms

From @chx :
"You are feeding a safe string to Html::normalize so the result will be safe too but the output is not necessarily the same as the input so the new string needs to be marked as safe too"

Then, maybe we could Html::normalize() *before* passing to Xss::filter() ?

Pinging the folks in #1798654: Clean faulty HTML in help description of field widgets.

Hm, what about making it a fancy trait? Has the limitation that only OO code can use it, but all calls in HEAD are already in classes.

Did not change anything about those calls, not sure how related it is for this issue, as I'm only moving it.

Trait works for me. Mostly nitpicks left.

1. --- /dev/null
   +++ b/core/lib/Drupal/Core/Field/AllowedTagsXssTrait.php
   

   Maybe this shouldn't live in Core/Field but somewhere more general, like in Component\Utility ?

2. +++ b/core/lib/Drupal/Core/Field/AllowedTagsXssTrait.php
   @@ -0,0 +1,52 @@
   +   * Filters an HTML string to prevent cross-site-scripting (XSS) vulnerabilities.
   

   80 chars

3. +++ b/core/lib/Drupal/Core/Field/AllowedTagsXssTrait.php
   @@ -0,0 +1,52 @@
   +   *   An XSS safe version of $string, or an empty string if $string is not valid
   

   same

4. +++ b/core/lib/Drupal/Core/Field/AllowedTagsXssTrait.php
   @@ -0,0 +1,52 @@
   +} ¶
   

   redundant space

Improved documentation. We agreed that we keep this trait in Core\Field for now.

Looks good to me. I was confused first about the removal of the static on sanitizeLabel() but it would now work anymore otherwise.

We need a change record because we're removing functions and introducing a trait.

Change record at https://www.drupal.org/node/2337599
Tentatively setting to RTBC again.

Needs a reroll

git ac https://www.drupal.org/files/issues/optional-field-module-2199637-37.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 21921  100 21921    0     0   119k      0 --:--:-- --:--:-- --:--:--  139k
error: patch failed: core/modules/options/src/Plugin/Field/FieldType/ListItemBase.php:7
error: core/modules/options/src/Plugin/Field/FieldType/ListItemBase.php: patch does not apply

Committed 5de9e40 and pushed to 8.0.x. Thanks!

diff --git a/core/modules/field/field.module b/core/modules/field/field.module
index 3f9e58c..ec8d2b7 100644
--- a/core/modules/field/field.module
+++ b/core/modules/field/field.module
@@ -4,9 +4,6 @@
  * Attach custom data fields to Drupal entities.
  */
 
-use Drupal\Component\Utility\Html;
-use Drupal\Component\Utility\SafeMarkup;
-use Drupal\Component\Utility\Xss;
 use Drupal\Core\Config\ConfigImporter;
 use Drupal\Core\Entity\EntityTypeInterface;
 use Drupal\Core\Extension\Extension;
diff --git a/core/modules/field/src/Plugin/views/argument/ListString.php b/core/modules/field/src/Plugin/views/argument/ListString.php
index b90baac..e78a9f7 100644
--- a/core/modules/field/src/Plugin/views/argument/ListString.php
+++ b/core/modules/field/src/Plugin/views/argument/ListString.php
@@ -10,7 +10,6 @@
 use Drupal\Component\Utility\String as UtilityString;
 use Drupal\Core\Field\AllowedTagsXssTrait;
 use Drupal\Core\Form\FormStateInterface;
-use Drupal\Core\Field\WidgetBase;
 use Drupal\views\ViewExecutable;
 use Drupal\views\Plugin\views\display\DisplayPluginBase;
 use Drupal\views\Plugin\views\argument\String;

Cleaned up the use statements on commit.