Add support for optional complex types to model building

[AndriySvyryd]

Breaking change: uniquify and validate complex type column uniqueness

Part of #31376

PR Overview

This pull request adds support for optional complex types to model building along with breaking changes to uniquify and validate complex type column uniqueness. Key changes include adding new APIs and configuration for complex property mapping in test and production code, modifying error conditions for complex properties, and renaming variables for clarity in runtime annotation code generation.

Reviewed Changes

File	Description
test/EFCore.Relational.Specification.Tests/LazyLoadProxyRelationalTestBase.cs	New test base for configuring complex properties with lazy loading proxies.
src/EFCore.Relational/Metadata/Conventions/SharedTableConvention.cs	Updates for determining uniqueness of complex property columns.
src/EFCore.Relational/Extensions/RelationalPropertyExtensions.cs	Refinements for ownership and complex type column naming logic.
src/EFCore.Relational/Infrastructure/RelationalModelValidator.cs	Additional validation for complex property mapping and concurrency token checks.
src/EFCore.Relational/Metadata/Internal/ComplexProperty.cs	Enforces non-nullability for complex properties that are collections.
test/EFCore.Relational.Specification.Tests/Migrations/MigrationsTestBase.cs	Test changes for column naming and nullability assertions.
src/EFCore.Relational/Design/Internal/RelationalCSharpRuntimeAnnotationCodeGenerator.cs	Renamed variable for clarity in generating runtime annotations.

Copilot reviewed 35 out of 35 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (4)

src/EFCore.Relational/Metadata/Conventions/SharedTableConvention.cs:240

• Ensure that using GetIdentifyingMemberInfo correctly handles all cases for both entity and complex types; add unit tests to cover edge cases if they are not already present.

var identifyingMemberInfo = property.GetIdentifyingMemberInfo();

src/EFCore/Metadata/Internal/ComplexProperty.cs:149

• The new check throws when a complex property marked as a collection is set to optional; please confirm that this breaking behavior is intentional and update documentation accordingly.

if (IsCollection) { throw new InvalidOperationException(CoreStrings.ComplexPropertyOptional(DeclaringType.DisplayName(), Name)); }

src/EFCore.Relational/Design/Internal/RelationalCSharpRuntimeAnnotationCodeGenerator.cs:1501

• The renaming to 'structuralTypeVariable' improves clarity over the previous 'entityTypeVariable'; please verify that all references have been updated consistently.

string structuralTypeVariable,

test/EFCore.Relational.Specification.Tests/Migrations/MigrationsTestBase.cs:2710

• [nitpick] Using Assert.True enhances readability; ensure that tests comprehensively cover scenarios for both required and optional complex properties.

Assert.True(c.IsNullable);

[SamMonoRT]

LGTM - only question was is there any performance implications with JIT or also NAOT scenario here?

[SamMonoRT]

Also for the new strings added, do we need any localization folks on review to trigger any follow up loc action?

[AndriySvyryd]

LGTM - only question was is there any performance implications with JIT or also NAOT scenario here?

No, this has no perf impact

Also for the new strings added, do we need any localization folks on review to trigger any follow up loc action?

We don't localize our strings