Move FieldInfo class to the DIC

Moving this to the core queue.

Having a Field::fieldInfo() method available soon would let us replace a large amount of the field_info_*() calls while we go over code that accesses $field and $instance definition structures in #1953408: Remove ArrayAccess BC layer from field config entities.

Would also provide a landing place for whatever comes out of #1953414: Move logic of field_read_fields() and field_read_instances() to the storage controller..

In short, it would be a good time to do this :-).

Any takers ? :-)

Added task summary

unclutter

fix title

Updated summary to point to #1961548: [Policy, no patch] Decide how the module-specific services are made available as static methods (similar to \Drupal::$service()) for the Field::fieldInfo() bit.

Yay !

Nitpicks :-):

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -1,20 +1,22 @@
  * A Drupal\field\FieldInfo object is created and statically persisted through
- * the request by the _field_info_field_cache() function. The object properties
- * act as a "static cache" of fields and instances definitions.
+ * the request by Field::FieldInfo. The object properties act as a

"statically persisted through the request by Field::FieldInfo".
Not really. Maybe skip this entire paragraph ? I don't think other services bother explaining their relation to the DIC and helper static methods.

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -33,6 +35,27 @@
+   * The cache backend to use.

Do we really need the ".. to use" prefixes ? Sounds a bit boilerplate.
(same in __construct() phpdoc)

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -33,6 +35,27 @@
+  protected $cacheBackend;

Similar use cases in core use both $this->cachebackend or $this->cache, but the latter seems a bit more common.
Brevity++ ?

+++ b/core/modules/field/lib/Drupal/field/FieldInfo.phpundefined
@@ -33,6 +35,27 @@
+   * Stores a module manager to invoke hooks.

Maybe just "The module manager." ?

Works for me.

Once again this looks like fine DX-cleanup, but please don't mark these patches as "major" when they're simple refactoring.

Committed and pushed to 8.x. Thanks!

Update issue link

There's a test that now gets random failures

Settings are changes in child process and entity_info_cache_clear() has no effect on field_info_cache

I've actually seen this happening in other tests as well, fixed that at least twice.

What I did was simply adding a field_info_cache_clear() above it and say "clear the cache" instead of skipping it. While that's a tiny bit slower, it's a typical pattern in tests I think.

Follow-up #2089807: Rename Field::fieldInfo() to FieldService::fieldInfo() for better DX

bolder changes