Improve the in-memory database provider

[ajcvickers]

This an "epic" issue for the theme of improvements to the in-memory database provider. Specific pieces of work will be tracked by linked issues.

Proposed for 7.0

• InMemory: Enable joins between sources which have client eval InMemory: Enable joins between sources which have client eval #21200

Backlog

• Add FK constraint checking to the in-memory provider Add FK constraint checking to the in-memory provider #2166
• Make InMemory provider enforce uniqueness of Alternate Keys Make InMemory provider enforce uniqueness of Alternate Keys #3850
• Cascade Delete Support InMemory: Cascade Delete Support #3924
• Throw DbUpdateException or DbUpdateConcurrencyException for in-memory database errors Throw DbUpdateException or DbUpdateConcurrencyException for in-memory database errors #23569
• InMemory DbContext does not respect CancellationToken on SaveChangesAsync InMemory DbContext does not respect CancellationToken on SaveChangesAsync #13368
• Defining query with shadow props InMemory: Defining query with shadow props #20023
• Rewrite query in a form that can be translated, or switch to client evaluation explicitly? Rewrite query in a form that can be translated, or switch to client evaluation explicitly? #25251
• Owned navigation for required dependent can generate join InMemory: Owned navigation for required dependent can generate join #26214
• A better implementation of DefaultIfEmpty InMemory: A better implementation of DefaultIfEmpty #17536
• Consider adding AddInMemoryDatabase sugar Consider adding AddInMemoryDatabase sugar #25487
• Support arrays of primitive types in in-memory database Support arrays of primitive types in in-memory database #11926

[binarypatrick]

Is this really needed? SQLite in memory is a great (better?) alternative.

[ajcvickers]

We recommend against using the in-memory provider for testing--see Testing EF Core Applications. While we have no plans to remove the in-memory provider, we will not be adding any new features to this provider because we believe valuable development time is better spent in other areas. When feasible, we plan to still fix regressions in existing behavior.