Migrate PostgreSql to TypeSpec

[mcgallan]

This PR migrates your latest version (identified by the tag in your readme.md) of swagger to TypeSpec. We already tried our best to make sure the TypeSpec represents same as previous swagger. Since we lack the business knowledge, please validate this PR again to make sure it's functional equivalent as before. The local validation step is at Getting started | TypeSpec Azure

Besides, TypeSpec encourages to follow ARM guidelines. Therefore, some representations in your previous swagger needs to be fixed. Please handle all these issues properly and them contact Azure SDK Team:

1.You're identifying that the TuningOptions_ListRecommendations operation uses an enum named recommendationType, which has the same name as another existing enum, but they contain different values. TypeSpec will treat them as the same enum during generation, which causes errors.

2.supportedHaMode has the same issue as recommendationType - there are duplicate enum names with different values that TypeSpec treats as the same enum during generation, causing conflicts.

3.the original swagger used the "x-ms-visibility": "internal" syntax, which doesn't have a corresponding syntax in TypeSpec.

4.the secret property in BackupStoreDetails is incorrectly placed within the items property, which is not the correct syntax.

5.threatProtectionName is an enum type, and when it's used as a parameter in the path, it cannot have a pattern added to it.

6.In TypeSpec, we cannot add a default value of null for model properties.
Please reach out to TypeSpec Discussions Channel if there is any help needed.

[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 has at least one change violating Azure versioning policy (label: VersioningReviewRequired).
  To unblock this PR, either a) introduce a new API version with these changes instead of modifying an existing API version, or b) follow the process at aka.ms/brch.

[openapi-pipeline-app]

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

[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.DBforPostgreSQL
TypeSpec	Microsoft.DBforPostgreSQL
Java	com.azure.resourcemanager:azure-resourcemanager-postgresql
JavaScript	@azure/arm-postgresql
Go	sdk/resourcemanager/postgresql/armpostgresql

[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).
• ❌ This PR has at least one change violating Azure versioning policy (label: VersioningReviewRequired).
  To unblock this PR, either a) introduce a new API version with these changes instead of modifying an existing API version, or b) follow the process at aka.ms/brch.
• ❌ The required check named Swagger Avocado has failed. 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

Comment generated by summarize-checks workflow run.

[nasc17]

Hi @mcgallan , we are currently planning to release a stable swagger in the next coming weeks. Should we have this migration based off what will soon be the newest version out? #36219

@mattboentoro for awareness

[nasc17]

@mattboentoro @nachoalonsoportillo

These issues were brought up in start of PR of causing conflicts:
1.You're identifying that the TuningOptions_ListRecommendations operation uses an enum named recommendationType, which has the same name as another existing enum, but they contain different values. TypeSpec will treat them as the same enum during generation, which causes errors.

2.supportedHaMode has the same issue as recommendationType - there are duplicate enum names with different values that TypeSpec treats as the same enum during generation, causing conflicts.

3.the original swagger used the "x-ms-visibility": "internal" syntax, which doesn't have a corresponding syntax in TypeSpec.

4.the secret property in BackupStoreDetails is incorrectly placed within the items property, which is not the correct syntax.

5.threatProtectionName is an enum type, and when it's used as a parameter in the path, it cannot have a pattern added to it.

6.In TypeSpec, we cannot add a default value of null for model properties.