Enable extensibility provider developers to specify diagnostic rules as part of provider definition

[lakshmimsft]

Is your feature request related to a problem? Please describe. Current implementation of Bicep doesn't allow extensibility providers to declare linting rules on the types that they define. This results in a degraded ability to relay constraints about the resource modeling to the author of the Bicep manifest.

[jeskew]

Could you share an example of the kind of linting rule you have in mind?

[lakshmimsft]

For a custom type, say, we allow users to specify custom labels and annotations. An example of their input could be:

resource customtype 'ExtensibleProviderType/typename' = {
  name: 'customtypename'
  location: location
  properties: {
    ...
    extensions: [
      {
        kind: 'customexttype'
        annotations: {
          'reservedkey/usertest': 'uservalue1'
        }
        labels: {
          'user.lbl.1': 'user.lbl.val.1'
        }
      }
    ]
  }
}

If users input entries begin with predetermined reserved words (as in the annotation above), we want to give them a warning indicating that they should not do so and describe how the system will behave if they continue with the entry etc. Including @asilverman to provide additional input.

[jeskew]

For that particular example, #8409 might be a better solution, but I see your point. Imported namespaces can define their own functions, types, and decorators, but the set of linter rules is fixed when the Bicep.Core DLL is compiled

[asilverman]

@alex-frankel could we add the 'extensibility-provider' label to this one?