Moving "feeds item" field in form display to non-disabled causes PHP error

@jnicola Thanks for the patch.

This problem makes it impossible to translate form display configurations of entities that have the Feeds Item field.
For more detailed information, I explained in comment #282
#2546212-282: Entity view/form mode formatter/widget settings have no translation UI

A feeds_item field wasn't meant to appear on the "Manage form display" page

The field type "feeds_item" has a "no_ui" property set to TRUE in its annotation. According to \Drupal\Core\Field\Annotation\FieldType that means:

/**
 * A boolean stating that fields of this type cannot be created through the UI.
 *
 * @var bool
 */
public $no_ui = FALSE;

So I assume this should mean that the field isn't supposed to appear on the "Manage form display" page. Could this perhaps be a bug in Drupal Core? Or did I misunderstood the purpose of the "no_ui" property here?
In Drupal Core, the following field types also have "no_ui" set: "changed", "created", "language", "map", "password", "uri" and "uuid". Some do have a default widget, but not all of them. At least some of these field types I don't see either on "Manage form display", like "uuid". So why is it that an "uuid" field on an entity does not cause trouble, but a "feeds_item" field does?

Commit patch as is?

Anyway, I see that the field is displayed on the "Manage form display". So maybe we should commit this patch as is (if it doesn't break any tests). I wasn't aware that it could cause trouble. Thought it was only a minor UX issue when accidentally dragging the field on the form display.

What a feeds_item field contains

I left a TODO in there to eventually display useful debug information for admins, if that's what even is contained in that field?

A feeds item field contains metadata about the imported entity. It tells when the entity was imported, with which feed entity it was imported and it has a hash value that is used by Feeds to determime if the source item has changed on a subsequent import. The properties "guid" and "url" can be mapped to. Perhaps it is useful to make these two properties editable with a widget.

no_ui property

From what I can see, the no_ui property in the field annotation is only used to prevent this from being listed when creating a new field in entities (/admin/config/people/accounts/fields/add-field).

Field form display configuration

The only way I know to prevent a field from appearing in the form's display list is to define the entity's base fields.
Eg. bellow: Defining the fields of the Feed entity (feeds_feed), if I didn't want the title field to be displayed in the form display setDisplayConfigurable('form', FALSE)
https://git.drupalcode.org/project/feeds/-/blob/8.x-3.x/src/Entity/Feed....

/**
  * {@heritdoc}
  */
public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
  $fields = [];
  ...
  $fields['title'] = BaseFieldDefinition::create('string')
   ->setLabel(t('Title'))
   ->setDescription(t('The title of this feed, always treated as plain text without markup.'))
   ->setRequired(TRUE)
   ->setDefaultValue('')
   ->setSetting('max_length', 255)
   ->setDisplayOptions('display', [
     'label' => 'hidden',
     'type' => 'string',
       'weight' => -5,
     ])
     ->setDisplayOptions('form', [
       'type' => 'string_textfield',
       'weight' => -5,
     ])
     ->setDisplayConfigurable('form', FALSE);
     ...
} 

That being said, it is completely useless in this case...

Feeds item widget

Although I don't see any use case where the feeds item field would be exposed, I think it would be the simplest solution.
Since this field stores internal feed processing information, would it be a good solution to have a readonly option in the widget?

@MegaChriz Thanks for the quick help.