[On hold] Refactored postgreSqlDatabases to handle secrets properly

[zachcasper]

Update: This PR is blocked on radius-project/radius#10890

Description

This pull request refactors and improves the configuration and deployment of PostgreSQL databases and Kubernetes secrets in the Radius platform. The goal is to establish a best practices pattern for other database resources. The main focus is on enforcing the use of external secrets for database credentials, updating documentation and schema to reflect this requirement, and enhancing the Kubernetes and Terraform recipes for better resource naming, labeling, and secret handling. Specifically:

1. Removes generating credentials in the Recipe
2. Adds the requirement to add a connection to a secret
3. Adds consistent labeling for Kubernetes resources
4. Synchronizes Bicep and Terraform recipes
5. Adds missing output resources on secrets recipe
6. Fixes double encoding issue Secrets Terraform Recipe double encodes key value when encoding is string #53
7. Updates developer documentation
8. Included test app.bicep with testing instructions embedded

Contributor Checklist

• File names follow naming conventions and folder structure
• Platform engineer documentation is in README.md
• Developer documentation is the top-level description property
• Example of defining the Resource Type is in the developer documentation
• Example of using the Resource Type with a Container is in the developer documentation
• Verified the output of rad resource-type show is correct
• All properties in the Resource Type definition have clear descriptions
• Enum properties have values defined in enum: []
• Required properties are listed in required: [] for every object property (not just the top-level properties)
• Properties about the deployed resource, such as connection strings, are defined as read-only properties and are marked as readOnly: true
• Recipes include a results output variable with all read-only properties set
• Environment-specific parameters, such as a vnet ID, are exposed for platform engineers to set in the Environment
• Recipes use the Recipe context object when possible
• Recipes are provided for at least one platform
• Recipes handle secrets securely
• Recipes are idempotent
• Resource types and recipes were tested

[Reshrahim]

Suggested some changes on removing secretName property as we decided to use resource name

[willtsai]

Can you add an example for the credentials secrets resource declaration here?

[brooke-hamilton]

Is this ready for review? The title says [WIP] so maybe I'm doing this too soon. There is one comment below, and I'll do more review if this is ready.

[brooke-hamilton]

Why would the secret be the only connection? Or if there are multiple, why would it be the first connection? Maybe a comment here would help explain.

[zachcasper]

This is the challenge with modeling the secret as a connection. @Reshrahim highlighted an inconsistency in how we are handling secrets.

@lakshmimsft's approach was to use connections from a database resource to a secret. We got some things for free, but I'll have to let her comment on what exactly the benefits of using connections was.

However, in the Containers Resource Type, @sk593 used the secretName and key which is more Kubernetes-like. This appears more straightforward since there can only be one secretName and key. Unlike connections which could be anything.

We should be consistent.

[zachcasper]

Is this ready for review? The title says [WIP] so maybe I'm doing this too soon. There is one comment below, and I'll do more review if this is ready.

It's on hold. Blocked by radius-project/radius#10890

[zachcasper]

Closing in lieu of #95