[META] Convert entity SQL queries to the Entity Query API

I think we can skip the search extender -- it'd be rather complicated to convert that one and everyone who uses nonsql uses solr or sphinx or searchapi or something.

Also note this is probably postponed on #2068655: Entity fields do not support case sensitive queries

This feels major in the sense I'd happily backport dbtng -> entity query conversions to point releases. On the other hand it'd be great to have 8.x-1.0 releases of alternative storage backends that actually work for all core entity queries - but downgrading until this blocks one of them.

I think so long there are direct queries to entities in core like that, we cannot say the storage is swappable.

Updated issue summary.

While working on comments conversion some questions appeared, which I think need to be discussed:

1. How do we decide which storage controller does something belong to. There are definitely many cases where this is not a question at all (most recent comments, most recent nodes, ...), but there are some "mixed" cases where I was not completely sure (example: get N most commented nodes). This kind of operation will return nodes, while it will definitely need to query against comment tables. It is a bit strange to return nodes from comment storage controllers and is also not very nice to query comment tables from node storage controller. I assume there will be some more cases like this and I think we should define general guidelines for this cases to prevent confusion and inconsistency in API.

2. Code that will use storage controllers to get some data sometimes expects entity ids and sometimes entirely loaded entities. We should probably define how we solve that, as it could also bring confusion. One option is to define naming conventions for storage controller functions that will reflect type of data we're returning. Another way to go would be to support both ways, which would be controlled with an argument.

While working on comments conversion some questions appeared, which I think need to be discussed:

1. How do we decide which storage controller does something belong to. There are definitely many cases where this is not a question at all (most recent comments, most recent nodes, ...), but there are some "mixed" cases where I was not completely sure (example: get N most commented nodes). This kind of operation will return nodes, while it will definitely need to query against comment tables. It is a bit strange to return nodes from comment storage controllers and is also not very nice to query comment tables from node storage controller. I assume there will be some more cases like this and I think we should define general guidelines for this cases to prevent confusion and inconsistency in API.

2. Code that will use storage controllers to get some data sometimes expects entity ids and sometimes entirely loaded entities. We should probably define how we solve that, as it could also bring confusion. One option is to define naming conventions for storage controller functions that will reflect type of data we're returning. Another way to go would be to support both ways, which would be controlled with an argument.

> How do we decide which storage controller does something belong to. There are definitely many cases where this is not a question at all (most recent comments, most recent nodes, ...), but there are some "mixed" cases where I was not completely sure (example: get N most commented nodes).

That's definitely tricky but again it's clearly comment: SELECT nid FROM comments GROUP BY nid ORDER BY COUNT(*) DESC -- it does return nodes but it's a comment query.

> Code that will use storage controllers to get some data sometimes expects entity ids and sometimes entirely loaded entities. We should probably define how we solve that, as it could also bring confusion.

Yes, there is some confusions around this. Given that we can always extract $ids from $entities with array_keys; I think we should standardize + fix those that pass $ids.

Added one more aggregator issue

Updating issue summary with sub-tasks.

Added #2205185: Split up ForumManager to create ForumIndexStorage at request of @andypost and @chx
This will move forum SQL queries from forum.module into ForumRepository

Not really an entity, but somehow related: #2209145: Move all path alias SQL queries to a single storage controller.

Updating issue summary.Moved node #2068333: Convert node SQL queries to the Entity Query API and forum #2205185: Split up ForumManager to create ForumIndexStorage under completed sub tasks list.

looks all child issues are fixed, can we close this one

Seems #2228733: Remove getFeedDuplicates - its unused and untested is open.

It is, but that's actually only related, not really a sub-issue. That is just moving a query that already is an entity query out of the storage class, because there is no reason for it to be there, as it is fully storage-agnostic.

So +1 to closing this.