feat: support labels and annotations for secrets

[arielsepton]

Description

This PR enhances secret management functionality for the DisposableRequest and Request resources by extending the SecretInjectionConfig field with the following updates:

1. Metadata Support:

   • Introduced a Metadata field to enable users to define labels and annotations for Kubernetes secrets created and managed by the DisposableRequest and Request resources.

2. KeyMappings Support:

   • Added a KeyMappings field to support injecting multiple key-value pairs into a single Kubernetes secret through a single SecretInjectionConfig.

3. Deprecations:

   • Marked the SecretKey and ResponsePath fields as deprecated. Users are encouraged to migrate to the more flexible KeyMappings field.

Why is this needed?

• Enhanced Metadata Handling:
  Enables users to attach labels and annotations to secrets, improving resource management.
• Improved Flexibility:
  Simplifies the management of multiple key-value pairs within a single secret, reducing configuration complexity.

Backward Compatibility

• Existing configurations using SecretKey and ResponsePath will continue to function but are now considered deprecated.

Testing

• Unit Tests:
  Extended test coverage to validate the behavior of the new Metadata and KeyMappings fields.
• Integration Tests:
  Verified the updated functionality for both DisposableRequest and Request resources in a Kubernetes cluster.

Related Issue

Resolves: #70

[drewburr]

@arielsepton just wanted to say thank you for implementing this for #70. Adding annotations and labels works perfectly, and KeyMappings with JQ resolved a lot of kruft that came with individual SecretKey and ResponsePath to extract data from a body. I was pleasantly surprised to see this added in and it's been great to work with

To share, our example use-case is we have an API that creates credentials against a database, basically a stripped down service broker used for Cloud Foundry. We use Crossplane to create a kind of DatabaseCredetential and provider-http serves to make the call to our API, then store the credentials as JSON in a secret, which is then mounted on a pod as a .json file. I'm very happy with how things are working with the changes introduced by this PR. Thanks again, your work is appreciated!

apiVersion: http.crossplane.io/v1alpha2
kind: DisposableRequest
metadata:
  name: example-database-credential
  namespace: my-namespace
spec:
  forProvider:
    body: |-
      {
        "app": "example-app",
        "database": "my-database"
      }
    expectedResponse: .body.password != null
    method: POST
    nextReconcile: 60s
    secretInjectionConfigs:
    - keyMappings:
      - responseJQ: .body | tostring
        secretKey: database-credentials.json
      metadata:
        labels:
          app: example-app
          database: my-database
      secretRef:
        name: database-credentials
        namespace: my-namespace
      setOwnerReference: true
    shouldLoopInfinitely: true
    url: https://database-credentials-api.example.com/credentials