Added new PreviewAlertRule API

[giladsub]

Added new PreviewAlertRule API

This API is used by the portal to simulate the rule creation in order to allow customers to better understand the behavior of the rule they configured.

[openapi-pipeline-app]

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).
• ❌ This PR is in purview of the ARM review (label: ARMReview). This PR must get ARMSignedOff label from an ARM reviewer.
  This PR is awaiting ARM reviewer feedback (label: WaitForARMFeedback).
  To learn when this PR will get reviewed, see ARM review queue at aka.ms/azsdk/pr-arm-review
  For details of the ARM review, see aka.ms/azsdk/pr-arm-review
  
• ❌ The required check named Automated merging requirements met has failed. This is the final check that must pass. Refer to the check in the PR's 'Checks' tab for details on how to fix it and consult the aka.ms/ci-fix guide. In addition, refer to step 4 in the PR workflow diagram

[openapi-pipeline-app]

PR validation pipeline restarted successfully. If there is ApiView generated, it will be updated in this comment.

[azure-sdk]

API Change Check

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

Language	API Review for Package
Swagger	Microsoft.AlertsManagement
Go	sdk/resourcemanager/alertsmanagement/armalertsmanagement

[giladsub]

Can the reviewer please help with the 2 last failing checks - specifically:

1. Requirement to remove query parameters for POST - in the future, we will be using this parameter to understand the schema of the payload (e.g. different ruleTypes will have different request schemas). In addition, ideally the request schema will be focused on the rule config, and configurations of the preview itself will be in the query parameters. Is it possible to get an exception on this?

2. I'm not sure why the SDK generation is failing - seems like it could be because some of the specs are using the common errorResponse, and others are using their own? If so, this is an issue that was introduced before this PR. Should I change the existing specs to use the common errorResponse or will this be consider a breaking change? Please advise...

Thanks! #Resolved

[rkmanda]

[giladsub]

@giladsub So just to check, I think I figured it out before but forgot - which commit ids are the best two to diff between if I want to review just what is new in this version compared to old API versions?

This is the first version of this API we are releasing #Resolved

[giladsub]

Can the reviewer please help with the 2 last failing checks - specifically:

1. Requirement to remove query parameters for POST - in the future, we will be using this parameter to understand the schema of the payload (e.g. different ruleTypes will have different request schemas). In addition, ideally the request schema will be focused on the rule config, and configurations of the preview itself will be in the query parameters. Is it possible to get an exception on this?

Did you solve these issues? My thought on 1 is that maybe you could use a different approach with discriminated types? See

"x-ms-discriminator"

Yes - we resolved it by putting in the body. Currently we don't need a discriminator since there is only one type we support, but when this becomes relevant down the line, we will update this in the future api-versions... #Resolved

[TimLovellSmith]

You must fix model validation failures #Resolved