refactor(resources): migrate to unified folder structure

[zedy-wj]

This PR migrates the resources specification to the new unified folder structure according to Azure folder structure guidelines.

Changes:

• Consolidated TypeSpec and Swagger files under resource-manager/Microsoft.Resources/bicep
• Consolidated TypeSpec and Swagger files under resource-manager/Microsoft.Resources/deploymentStacks
• Based on the readme.md file under the resource-manager path, the following services are extracted:

1. Microsoft.Authorization/locks
2. Microsoft.Authorization/policy
3. Microsoft.Authorization/privatelinks
4. Microsoft.Features/features
5. Microsoft.Resources/changes
6. Microsoft.Resources/databoundaries
7. Microsoft.Resources/links
8. Microsoft.Resources/resources
9. Microsoft.Resources/snapshots
10. Microsoft.Resources/subscriptions
11. Microsoft.Solutions/managedapplications
12. Add suppressions.yaml files under service folders with new folder structure.

• Updated tspconfig.yaml with correct paths.
• Fixed input-file paths in readme.md
• Verified TypeSpec compilation works correctly

Benefits:

• Unified structure for better maintainability
• Aligns with Azure folder structure standards
• Maintains backward compatibility
• Supports future TypeSpec migration efforts

[github-actions]

Next Steps to Merge

Next steps that must be taken to merge this PR:

• ❌ This PR targets either the main branch of the public specs repo or the RPSaaSMaster branch of the private specs repo. These branches are not intended for iterative development. Therefore, you must acknowledge you understand that after this PR is merged, the APIs are considered shipped to Azure customers. Any further attempts at in-place modifications to the APIs will be subject to Azure's versioning and breaking change policies. Additionally, for control plane APIs, you must acknowledge that you are following all the best practices documented by ARM at aka.ms/armapibestpractices. If you do intend to release the APIs to your customers by merging this PR, add the PublishToCustomers label to your PR in acknowledgement of the above. Otherwise, retarget this PR onto a feature branch, i.e. with prefix release- (see aka.ms/azsdk/api-versions#release--branches).

Comment generated by summarize-checks workflow run.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
Swagger	Microsoft.Authorization-bicep
Swagger	Microsoft.Authorization-changes
Swagger	Microsoft.Authorization-databoundaries
Swagger	Microsoft.Authorization-deploymentStacks
Swagger	Microsoft.Authorization-features
Swagger	Microsoft.Authorization-locks
TypeSpec	BicepClient
TypeSpec	Microsoft.Resources.DeploymentStacks
Swagger	Microsoft.Authorization-privatelinks
Swagger	Microsoft.Authorization-snapshots
Swagger	Microsoft.Authorization-subscriptions
Swagger	Microsoft.Authorization-managedapplications
Swagger	Microsoft.Authorization-resources
Java	com.azure.resourcemanager:azure-resourcemanager-resources-deploymentstacks
Java	com.azure.resourcemanager:azure-resourcemanager-resourceslocks
Java	com.azure.resourcemanager:azure-resourcemanager-resourcespolicy
Java	com.azure.resourcemanager:azure-resourcemanager-resourcesprivatelinks
Java	com.azure.resourcemanager:azure-resourcemanager-resourcesfeatures
Java	com.azure.resourcemanager:azure-resourcemanager-resourceschanges
Java	com.azure.resourcemanager:azure-resourcemanager-resourcesdataboundaries
Java	com.azure.resourcemanager:azure-resourcemanager-resources-deploymentscripts
Java	com.azure.resourcemanager:azure-resourcemanager-resourcesdeployments
Java	com.azure.resourcemanager:azure-resourcemanager-resourcesresources
Java	com.azure.resourcemanager:azure-resourcemanager-resourcessnapshots
Java	com.azure.resourcemanager:azure-resourcemanager-resourcessubscriptions
Java	com.azure.resourcemanager:azure-resourcemanager-resources-templatespecs
Java	com.azure.resourcemanager:azure-resourcemanager-resourcesmanagedapplications
Go	sdk/resourcemanager/resources/armdeploymentstacks
Go	sdk/resourcemanager/resources/armpolicy
Go	sdk/resourcemanager/resources/armchanges
Go	sdk/resourcemanager/databoundaries/armdataboundaries
Go	sdk/resourcemanager/resources/armdeploymentscripts
Go	sdk/resourcemanager/resources/armmanagedapplications
Python	azure-mgmt-resource-bicep
Python	azure-mgmt-resources-deploymentstacks
Python	azure-mgmt-resource
Python	azure-mgmt-resource-deploymentscripts
Python	azure-mgmt-resource-deployments
Python	azure-mgmt-resource-templatespecs
JavaScript	@azure/arm-resourcesbicep
JavaScript	@azure/arm-resourcesdeploymentstacks
JavaScript	@azure/arm-locks
JavaScript	@azure/arm-policy
JavaScript	@azure/arm-features
JavaScript	@azure/arm-changes
JavaScript	@azure/arm-databoundaries
JavaScript	@azure/arm-resourcesdeploymentscripts
JavaScript	@azure/arm-resourcestemplatespecs
JavaScript	@azure/arm-managedapplications
Swagger	Microsoft.Authorization-links
Java	com.azure.resourcemanager:azure-resourcemanager-resourceslinks
JavaScript	@azure/arm-links

[qiaozha]

The semantic error is reported because there's two APIs that are semantical equivalent.
/{applicationId}
/{applicationDefinitionId}

And those APis are not even ARM APIs. those errors are from apiVersion 2016-09-01-preview and 2017-09-01 which has been supersede by the latest preview and stable version.

I will add suppression for it.

Let me know if @mikeharder or @raych1 has any concerns about it.

[qiaozha]

This PR is trying to refactor the specification/resources and the new folder structure is showing as the below, where each leaf node here is representing a service (which previously isolated by tags like package-policy-* etc) according to this guideline.

specification/resources
├── cspell.yaml
└── resource-manager
    ├── Microsoft.Authorization
    │   ├── locks
    │   ├── policy
    │   └── privatelinks
    ├── Microsoft.Features
    │   └── features
    ├── Microsoft.Resources
    │   ├── bicep
    │   ├── changes
    │   ├── databoundaries
    │   ├── deploymentScripts
    │   ├── deploymentStacks
    │   ├── deployments
    │   ├── links
    │   ├── resources
    │   ├── snapshots
    │   ├── subscriptions
    │   └── templateSpecs
    └── Microsoft.Solutions
        └── managedapplications

Each service will have its own swagger and TypeSpec and tracked the reference by the corresponding independent readme.md files.

[sandipsh]

I see lots of swagger avocado/lintdiff errors. i know this is just folder restructuring but errors like missing readme.md saying sdk won't be generated makes me nervous. Please take a closer look to ensure we are not breaking stuff here, @zedy-wj, and confirm your findings.

[qiaozha]

I see lots of swagger avocado/lintdiff errors. i know this is just folder restructuring but errors like missing readme.md saying sdk won't be generated makes me nervous. Please take a closer look to ensure we are not breaking stuff here, @zedy-wj, and confirm your findings.

@sandipsh hi, this is a known issue to the tooling and tracked here, the SDK generation won't have any impact here.

[qiaozha]

@zedy-wj please work with members from each SDK team to fix the SDK generation failure. thanks!

[zedy-wj]

@zedy-wj please work with members from each SDK team to fix the SDK generation failure. thanks!

I have already contacted the relevant SDK team members and am working on addressing the SDK generation failures.