Align modules to envisioned child-resource structure

[rahalan]

Following several length discussions around the handling of child-resources in the repository we agreed upon one approach that we now need to align all modules with. The general motiviation is to present a consistent approach across all modules that not only eases consumption but also contribution.

These are the plans we agreed upon:

• Each resource has only one pipeline. There will not be pipelines for child resources.
• Child-resources should reside in their own folder inside the corresponding parent. For example: The child 'containers' of module 'StorageAccounts' should have its template & readme in the folder 'arm/Microsoft.Storage/storageAccounts/containers'
• Each child-resource folder should have one deploy.bicep, one readme.md (-> how to use the template), optionally a .bicep folder for related providers, etc. (like nested_rbac / nested_cuaId) and can have n-amount of further child-resource folders in it (-> Further nesting)
• Each resource should refer to it's sub-resources with a 'module .<folderName>.deploy.bicep' reference
• The resource should provide a parameter (e.g. array) for the correponding sub-resource. For example, the storageAccount template should have a parameter 'containers' that is passed into the container module reference
• No childresource should be configured as a child-resource inside the parent resource. In terms if ARM that would mean that you don't leverage the nested 'resources' property of a resource. In bicep that means you don't have a resource inside the resource-definition of another resource. These resources are usually easy to detect as they only specifiy the child-resource identifier. For example: 'containers@' instead of 'Microsoft.StorageAccounts/storageAccounts/containers@'
• All 'parameters' folders should be renamed to '.parameters' as that directly identifies them as module-level specific folders
• If there are any existing parameter files for child-resources (e.g. for API in case of APIServiceManagement) we should merge these into the top-level parameter file and remove the original. All tests will be executed from that level. This will potentially result in multiple parameter files to test different combinations
• All child-resources are published as individual templates for users to consume, once tested

Terminology

• ChildResource: Child-resources are resources that are direct decendents of a top-level resource. For example: For a top-level resource 'Microsoft.Storage/StorageAccounts' we may have child-resources like 'Microsoft.Storage/StorageAccounts/containers'. However, this is not the same as a provider (e.g. Microsoft.Storage/StorageAccounts/providers/locks). These are not considered child-resources but extension resources

[AlexanderSehr]

@rahalan I guess this Issue should be split into individual issues for individual modules
Erika was so keen to greate an issue for all resources that have a 'resources' folder. However, we actually have way more modules with child-resources that just happened to be embedded in the parent. So we should go through the modules and create an issue each on that basis too