Add EF Core specification test suite (FunctionalTests project)

[j-d-ha]

Why

EF Core publishes an official specification test suite that all providers are encouraged to implement. These tests verify that the provider correctly executes the full range of LINQ queries and returns expected results. They serve as the primary regression mechanism for EF Core's own providers (SQL Server, SQLite, Cosmos) and are continuously expanded with new EF Core features. Without them, our coverage relies entirely on hand-written unit/integration tests which cannot keep pace with EF Core's evolving feature surface.

What Needs To Be Done

1. Create a new xUnit test project: EntityFrameworkCore.DynamoDb.FunctionalTests
2. Reference Microsoft.EntityFrameworkCore.Specification.Tests NuGet package (non-relational provider variant)
3. Implement the required test infrastructure:
   • DynamoDbTestStore / DynamoDbTestStoreFactory — provisions DynamoDB Local via Testcontainers (Testcontainers.DynamoDb) for spec test datasets; each test store lifecycle spins up/tears down a container
   • DynamoDbNorthwindTestStoreFactory — seeds the Northwind dataset used by most spec tests
   • Base fixture classes following the pattern from other providers
4. Start by extending NorthwindWhereQueryTestBase → NorthwindWhereQueryDynamoDbTest as the initial beachhead
5. Incrementally add more spec test classes (GroupBy, OrderBy, Select, Include, etc.), skipping/noting tests that require unsupported features
6. Eventually add DynamoDbComplianceTest extending ComplianceTestBase to track which upstream spec classes are covered and alert when EF Core adds new ones
7. Add optional PartiQL assertions (analogous to SQL assertions in relational providers) for translation coverage

Acceptance Criteria

• FunctionalTests project builds and runs against DynamoDB Local (via Testcontainers)
• At minimum, NorthwindWhereQueryDynamoDbTest class exists with a meaningful subset of tests passing
• CI runs the spec tests
• Failing/skipped tests are explicitly documented (not silently ignored)

Design Notes

• Use the non-relational spec test package (Microsoft.EntityFrameworkCore.Specification.Tests), not the relational variant
• DynamoDbTestStore uses Testcontainers.DynamoDb to manage DynamoDB Local container lifecycle — consistent with how the existing integration test suite provisions DynamoDB Local
• Reference the Mongo and Cosmos provider spec test implementations as structural guides (both are non-relational)
• PartiQL assertions are optional — correctness (row results) is the primary bar; PartiQL shape is secondary
• Use EF_TEST_REWRITE_BASELINES=1 pattern for bulk PartiQL baseline updates if PartiQL assertions are adopted
• Spec tests are large; cherry-picking test classes and growing coverage incrementally is explicitly endorsed by the EF Core team

References

• https://learn.microsoft.com/en-us/ef/core/providers/writing-a-provider#the-ef-core-specification-tests
• https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.Specification.Tests
• EF Core spec tests source: https://github.com/dotnet/efcore/tree/main/test/EFCore.Specification.Tests
• Cosmos spec tests (reference impl): https://github.com/dotnet/efcore/tree/main/test/EFCore.Cosmos.FunctionalTests
• Testcontainers.DynamoDb: https://dotnet.testcontainers.org/modules/dynamodb/