Hierarchy building

[radhgupta]

This pull request introduces a new dual constructor pattern for intermediate models in discriminated union hierarchies, ensuring correct instantiation and inheritance when models share discriminator property names with their base models. It adds logic to detect when this pattern is needed, generates the appropriate constructors, and updates constructor initialization to support multi-layer discriminator scenarios. Several new tests are included to validate these changes.

Constructor Pattern Enhancements

• Added a new ConstructorType enum to define different constructor generation strategies, supporting public, private protected, and internal constructors for various use cases.
• Implemented logic in ModelProvider to detect when a model should use the dual constructor pattern (i.e., when it shares a discriminator property name with its base and has derived models).
• Added methods to generate three constructors for intermediate discriminated models: a public constructor (for external use), a private protected constructor (for inheritance), and an internal constructor (for serialization).

Constructor Initialization Logic

• Updated constructor initialization to correctly call the appropriate base constructor, including passing discriminator values when required for intermediate models using the dual constructor pattern.

Testing Multi-Layer Discriminator Hierarchies

• Added comprehensive tests to cover multi-layer discriminator scenarios, including cases with and without discriminator properties at intermediate layers, and verifying correct constructor argument initialization.

Minor Cleanup

• Removed an unused discriminatedKind argument in a test setup for clarity.

Addresses: Azure/azure-sdk-for-net#51958

[github-actions]

No changes needing a change description found.

[JoshLove-msft]

I think the filtering that we need to adjust happens here - https://github.com/microsoft/typespec/blob/main/packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/Providers/ModelProvider.cs#L586-L594. That filtering is designed for only one layer of inheritance for a single discriminator. Now that we support N layers for a single discriminator, we need to adjust the condition. This will allow us to not have special handling for creating the discriminator param, and the name/description will come directly from the property.

[radhgupta]

Oh, so do you mean that rather than creating the discriminator parameter, I simply remove the if (isDirectBase) from GetAllBasePropertiesForConstructorInitialization this way I dont have to create the discriminator and do not need to create includeDiscriminatorParameter flag in BuildConstructorParameters?

[JoshLove-msft]

I think we still need some logic to do what the isDirectBase is currently doing. The purpose of that was so that we don't add base properties when there are nested discriminators from an ancestor further than the direct base. So I think you are right we can remove the isDirectBase check but we will need to add a new check that the discriminator property from the base model matches the current model's discriminator property.

[JoshLove-msft]

nit: I think we don't need these anymore

[JoshLove-msft]

Can we compute this and store in a field called _isMultiLevelDiscriminator?

[JoshLove-msft]

I think this should be if (isDirectBase || _isMultiLevelDiscriminator)

[JoshLove-msft]

Actually we probably need to add a parameter in this method (and check that instead) since we only want to do this for one of the constructors for multilevel discriminator models. Something like:

if (isDirectBase || includeHierarchyDiscriminator)

[JoshLove-msft]

if it is a multiLevelDiscriminator I think we can just add the additional constructor and let the other constructor creation happen as is

[JoshLove-msft]

Looks like the CI is failing