x-ms-identifiers alternative

[timotheeguerin]

Design approved

1. Use @key whenever possible(including new multiple key feature added by microsoft/typespec
2. If the default behavior is not suitable add a new decorator @identifiers

extern dec identifiers(target: ModelProperty, properties: ModelProperty[]);

function getModelIdentifiers(program: Program, model: Model): ModelProperty[];

decorator could potentially validate that the identifier specified are not the same as the default ones

[markcowl]

Proposal is here:https://gist.github.com/markcowl/d316ff4566aa04c5332c33402fbd218c

• Relax checks for multiple keys in REST library
• Add identifiers decorator and accessor into typespec-azure-core

[AlitzelMendez]

Adding more information, as talked with Mark offline about this issue and he shared with me more insights:

The expectation for this issue is:

• Add a decorator in typespsec-azure-resourcemanager that sets the x-m-identifiers for a model type or an array model property
• Add a helper in the same library that will determine the x-ms-identifiers values for an array property, either from applications of the decorator above, or from properties marked as keys.
• Update typespec-autorest to use this new helper to emit x-ms-identifiers
• When looking at specs, remove any use of extension decorators, then determine which specs need to be updated with the new decorator

The idea is that the default is to collect and use the 'key' properties to determine the identifiers, but for existing specs, in cases where this does not produce the right result, use the new decorator to mimic the x-ms-identifiers they previously set through extensions