give azure app registrations their own fields

[Morriz]

User story

As a user, I want to configure azure app registrations , so I can target different resources

Background

Azure values are highly dependent on app registrations, and as such usually have the following fields:

• tenantId
• subscriptionId
• clientId
• clientSecret

We now have those properties set on our top-level azure prop, which are re-used in many locations. This is problematic, as it assumes app registrations share those fields.

We should offer the same fields in all locations that an app registration is used, but still default to the top-level props for missing fields.

Locations that need it:

• ?

Use cases

1. A user can configure all Azure app registrations in otomi-values

Definition Of Ready

• [ ] Requirements have been reviewed, agreed and locked in discussion:
• [ ] The story is self-contained and has no dependencies
• [ ] The story is reviewed and approved by the stake holders
• [ ] The story has been estimated in complexity points
• [ ] The story use cases are clear and can be translated into test scenarios
• [ ] SMART tasks have been created that reflect the functional requirements from the discussion

Tasks

core:

1. [ ] Update schema
2. [ ] Update demo values

Definition Of Done

• [ ] Tasks are done.
• [ ] (Unit) Tests are added with the code (if relevant and practical)
• [ ] (Architecture) Design Record(s) have been added as adr/*.md and appended to list in adr/_index.md.
• [ ] Schema and demo files have been updated to reflect code changes (if relevant).
• [ ] Documentation has been updated (if relevant).
• [ ] Functionality, code, and/or documentation have been peer reviewed.