UseConnectionPaging on a nested EF collection fails: LINQ expression could not be translated #574

Problem

UseConnectionPaging() on a field that is not on the root query type fails when its collection comes from EF, for example a navigation property:

schema.Type<Actor>()
    .ReplaceField("movies", a => a.Movies.OrderByDescending(m => m.Released), "Movies, newest first")
    .UseConnectionPaging();

{ actor(id: 1) { movies(first: 1) { totalCount edges { node { name } } } } }

Field 'actor' - The LINQ expression 'edgeNode => ...' could not be translated.

The test models in EntityGraphQL.EF.Tests (SQLite) are enough to reproduce it. The offset paging version of this bug is fixed in #573.

Cause

There are two problems, and fixing the first one exposes the second.

1. ConnectionEdgeExtension pages the edges with EntityGraphQL's own EnumerableExtensions.Skip/Take(int?). A nested collection depends on the parent row and is part of the parent's projection, so EF has to translate the call, and it doesn't know these helpers. On a root field this is fine, because EF evaluates the call before translating. Fix UseOffsetPaging on a nested EF collection #573 fixes this for offset paging by using System.Linq's Skip/Take when the collection isn't an IQueryable.
2. Applying that same change here gets past the first error, but the query then fails with The LINQ expression 'newEdgeParam ...' could not be translated. ProcessExpressionSelection wraps the edge Select in ConnectionHelper.ApplyCursors(...), which assigns cursors while enumerating in memory. That works for a root field, where that call is what runs the DB query. In a nested projection EF has to translate it, and it can't.

So nested connection paging needs cursors built in a way EF can translate (or added after the query runs), not just the Skip/Take change.

Workaround

Expose the collection as a root query field that takes the parent id, and page that instead.