create SAA fields as fulltext rather than append them to the rendered item in hook_entity_view()

Problem/Motivation

I can't actually figure out how search_api_attachments_entity_view() works -- AFAICT it's going *back into* the search index, and getting the value of the SAA text fields to append them to the entity build array.

I don't understand how that works when the entity is being rendered during the indexing process -- how does the index have the entity already?

Regardless, it doesn't seem very clean or efficient:

We're loading ALL indexes:

    $indexes = Index::loadMultiple();
    foreach ($indexes as $index) {

and then for each SAA index field (which are defined for the index by the FilesExtractor processor), we load the item for the current entity (although -- 🐛 search_api_attachments_entity_view() assumes the entity is a node Active !):

          ($query = \Drupal::entityTypeManager()
            ->getStorage('search_api_index')
            ->load($index->id())
            ->query()
          )
            ->addCondition('nid', $entity->id());

          $items = $query->execute()->getResultItems();

          $item = reset($items);
          $content = $item->getField($field)->getValues()[0];

and then add its text output to the entity's build array:

          $build[$field] = [
            '#plain_text' => $content->getText(),
          ];

But we've done that for ALL indexes! So if the same entity is in 3 indexes, we've just queried for it 3 times, and obtained the text for the SAA field 3 times.

Given this, I wonder whether this is part of the cause of memory issues I've been seeing ( 🐛 Fatal error - memory exhausted Active ).

Proposed resolution

Instead of declaring SAA index fields as text fields and then putting them into the entity render, declare them as fulltext fields.

They can then be indexed directly by SearchAPI as such.

Both Views and SearchAPI Pages have options for which fulltext fields are searched by a fulltext search, with the option to search all fulltext fields.

This would vastly simplify this module's process, and remove the need for search_api_attachments_entity_view() going back into the index(es).

Remaining tasks

User interface changes

API changes

Data model changes