Fix to #21006 - Support a default value for non-nullable properties

[maumar]

Only for scalar properties when projecting Json-mapped entity. Only need to change code for Cosmos - relational already works in the desired way after the change to streaming (properties that are not encountered maintain their default value) We still throw exception if JSON contains explicit null where non-nullable scalar is expected.

Fixes #21006

[maumar]

This is now ready for review.

Tested (and working) scenarios:
project entity with missing required property
project entity with null-value required property
project missing required navigation
project null-value required navigation (works on Cosmos, throws validation error on relational)

tested top level and nested, as well as properties requiring converters vs no.

what doesn't work:
project missing required property directly
project null-value required property directly

to make it work users need to cast to nullable, otherwise we throw nullable object must have a value. This would be quite tricky to fix - when we project properties directly, we lose the IProperty information, so we can't easily reason with what is being projected (type doesn't provide any hints, it's always nullable - a requirement we check at the start of CreateGetValueExpression). It should be ok, given that workaround is very easy.

[Copilot]

PR Overview

This PR fixes issue #21006 by ensuring that non-nullable scalar properties on JSON‐mapped entities get a proper default value when they are missing during projection. Key changes include new test scenarios for Cosmos, Sqlite, and SQL Server providers, as well as modifications to the Cosmos projection binding logic to correctly handle non-nullable scalars.

Reviewed Changes

File	Description
test/EFCore.Cosmos.FunctionalTests/Query/AdHocCosmosTestHelpers.cs	Introduces a helper to create entities in Cosmos with JSON payloads (note a spelling mistake in one of the error messages).
test/EFCore.Cosmos.FunctionalTests/Query/AdHocMiscellaneousQueryCosmosTest.cs	Adds tests for projecting entities with missing scalar values and navigations.
test/EFCore.Sqlite.FunctionalTests/Query/AdHocJsonQuerySqliteTest.cs	Adds insert scripts to cover scenarios with missing and null scalars/navigations.
test/EFCore.SqlServer.FunctionalTests/Query/AdHocJsonQuerySqlServerTestBase.cs	Updates base test class to validate SQL output for various missing value cases.
test/EFCore.Relational.Specification.Tests/Query/AdHocJsonQueryRelationalTestBase.cs	Revises model building and overrides tests for missing required values.
src/EFCore.Cosmos/Query/Internal/CosmosShapedQueryCompilingExpressionVisitor.CosmosProjectionBindingRemovingExpressionVisitorBase.cs	Adjusts the expression visitor logic to account for non-nullable scalars.
test/EFCore.InMemory.FunctionalTests/InMemoryComplianceTest.cs	Registers the new AdHocJsonQueryTestBase in the in-memory test suite.

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

[AndriySvyryd]

project missing required navigation
project null-value required navigation (works on Cosmos, throws validation error on relational)

Does it work in the sense that navigation remains null or do we create an empty entity?

[maumar]

@AndriySvyryd returns null for the missing navigations

        Assert.Equal(default, missingRequiredNav.RequiredReference.NestedRequiredReference);
        Assert.Equal(default, missingRequiredNav.OptionalReference.NestedRequiredReference);
        Assert.True(missingRequiredNav.Collection.All(x => x.NestedRequiredReference == default));

[roji]

@maumar as a general rule, can we please avoid testing things on DateTimes (as opposed to strings and ints) where we're not specifically testing timestamp stuff? Support for timestamps really does vary across databases (whereas it doesn't for e.g. ints), and this fails on PG without some significant tweaking (since you can't shove an Unspecified DateTime into the default PG timestamp type).

Basically let's default to the basic, unproblematic types (int, string) unless we're specifically wanting to test DateTime behavior.