feat(docs): add ADR for Plugin lifecycle

[IvoGoman]

TL;DR;

This ADR proposes to introduce PluginDefinitionRevisions to enable version pinning on PluginPreset and Plugin resources. PluginPresets will support semantic version constraints, while Plugins, due to technical limitations, will only support concrete versions.
This will enable to stagger a rollout of a new PluginDefinition version by using a concrete version tag on the PluginPreset referring to this PluginDefinition. There is still the option to perform automatic upgrades as before.
Greenhouse will provide the means to use any given CD/GitOps/etc. way to deploy these manifests, but it will not provide an out of the box way to deploy the Greenhouse manifests of an Organization into it's namespace.
Garbage-collection of these revisions is proposed to delete the oldest unused revision/version over a count of maxRevision. This way gradually over time older revisions can be removed as soon they are no longer used.

[github-actions]

This PR is stale because it has been open for 45 days with no activity.

[github-actions]

This PR was closed because it has been inactive for 14 days since being marked as stale.

[abhijith-darshan]

as a first proposal for the PluginCatalog we could do -

apiVersion: greenhouse.sap/v1alpha1
kind: PluginCatalog
metadata:
  name: catalog
  namespace: <org-name>
spec:
  sources:
    - github:
        repoURL: https://github.com/cloudoperators/greenhouse
        secretRef:
          name: github-token
          key: github
          mapping:
            token: token
            appID: appID
            privateKey: privateKey
        targetRevision: main
        path: perses/plugindefinition.yaml # (Explicit path to plugin definition file or can it be directory containing plugin definitions and controller parses all yamls in the base of the dir and extracts all plugin definitions?)
        paths:
          - perses/plugindefinition.yaml
          - alerts/plugindefinition.yaml
          - exposed-services/plugindefinition.yaml
        syncOptions:
          syncInterval: 1h # (How often to sync the catalog with the source)
          automated: true # (Automatically sync the catalog with the source) (mutually exclusive with syncInterval - if syncInterval is set, automated is ignored)
          prune: true # (Remove plugindefinitions that are not in the source) (default: false)

## Do we support buckets?? Many buckets (s3, GCS) support version number or timestamp or generation number, we can use that to check for sync

In target revision we can do -

Pinning Strategies

• branch name,
• commit hash,
• v tag

Watch Strategies on tags or releases

• v1.x.x

[IvoGoman]

as a first proposal for the PluginCatalog we could do -

apiVersion: greenhouse.sap/v1alpha1
kind: PluginCatalog
metadata:
  name: catalog
  namespace: <org-name>
spec:
  sources:
    - github:
        repoURL: https://github.com/cloudoperators/greenhouse
        secretRef:
          name: github-token
          key: github
          mapping:
            token: token
            appID: appID
            privateKey: privateKey
        targetRevision: main
        path: perses/plugindefinition.yaml # (Explicit path to plugin definition file or can it be directory containing plugin definitions and controller parses all yamls in the base of the dir and extracts all plugin definitions?)
        paths:
          - perses/plugindefinition.yaml
          - alerts/plugindefinition.yaml
          - exposed-services/plugindefinition.yaml
        syncOptions:
          syncInterval: 1h # (How often to sync the catalog with the source)
          automated: true # (Automatically sync the catalog with the source) (mutually exclusive with syncInterval - if syncInterval is set, automated is ignored)
          prune: true # (Remove plugindefinitions that are not in the source) (default: false)

## Do we support buckets?? Many buckets (s3, GCS) support version number or timestamp or generation number, we can use that to check for sync

In target revision we can do -

Pinning Strategies

• branch name,
• commit hash,
• v tag

Watch Strategies on tags or releases

• v1.x.x

This PR is concerning the lifecycle, could you add your comment to #20 instead?