SelectMany over primitive collection property fails

[roji]

Query:

_ = await ctx.Blogs.SelectMany(b => b.Tags).ToListAsync();

Full repro

await using var ctx = new BlogContext();
await ctx.Database.EnsureDeletedAsync();
await ctx.Database.EnsureCreatedAsync();

ctx.Blogs.AddRange(
    new Blog { Tags = new List<string> { "tag1", "tag2" } },
    new Blog { Tags = new List<string> { "tag2", "tag3" } });

_ = await ctx.Blogs.SelectMany(b => b.Tags).ToListAsync();

public class BlogContext : DbContext
{
    public DbSet<Blog> Blogs { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        => optionsBuilder
            .UseSqlServer("Server=localhost;Database=test;User=SA;Password=Abcd5678;Connect Timeout=60;ConnectRetryCount=0;Encrypt=false")
            .LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging();
}

public class Blog
{
    public int Id { get; set; }
    public List<string> Tags { get; set; }
}

The cause of the issue is that the SelectMany lambda is visited by the top-level QueryableMethodTranslatingExpressionVisitor - not by a subquery visitor. Our code for identifying the property access (b.Tags) kicks in only after the regular translation failed (code); but the base visitation throws before that when translation fails on a non-subquery visitor (code).

[roji]

Fix options:

1. Move identification of property access to before calling base.Visit (possibly a bit heavy)
2. Stop eagerly throwing in VisitMethodCall, throw only on top-level Translate method
3. Instantiate a subquery visitor instance for the SelectMany lambda translation
4. Preferred: move property access identification up to core (QueryableMethodTranslatingExpressionVisitor); this would start building support for primitive collections in non-relational providers.

[roji]

Did option 4 above.

If further users run into the SelectMany issue, we can consider patching with a simpler fix.