Use external_entities to declare Unomi types as Drupal entities

Update: I've made quite a lot of progress with this.

I've got Unomi entities defined as Drupal entities. There's a lot less boilerplate code for the admin UI, but to counterbalance that, there's lots more code to declare things to the entity system - entity type class, storage client and field mapper plugins, and then (hopefully) temporary code to work around ✨ Define entity types programmatically Active .

I prefer it like this, because it's code that works with existing, standard systems.

However, as it's a big change I'd like input from the project owner -- should this be a new major version of this module, or should it be a forked new project?

I've hit a bit of an issue -- the entity list builder makes a remote request to run the entity query, and THEN runs a request for EVERY entity to load it to show in the list.

I'm sure there's a way to work around it, but it might end up being fiddly.

- making the EE storage client plugin cache the query result won't work, because Unomi list queries don't return complete entities, AFAICT they return what's inside the metadata property of a full entity.
- changing the query to return all the data won't work - it's totally changing how entity queries work, which is they just return IDs
- we could override list builder's load() method so it doesn't do a query, just a loadMultiple(). But then we don't get the paging functionality which would have scaling implications for the list pages of profiles and events

Pushed work in progress to a branch.

> - we could override list builder's load() method so it doesn't do a query, just a loadMultiple(). But then we don't get the paging functionality which would have scaling implications for the list pages of profiles and events

I'm leaning towards a variation of this -- we add a new method to the storage backend for queries that return metadata.