feat: Add objectLockConfiguration (mode/days) and versioning parameters to Tenant bucket spec

[optical4eye]

Is your feature request related to a problem? Please describe.

Currently, the Tenant CRD allows creating buckets via spec.buckets, but it only has a simple objectLock: true/false boolean flag.

There are no fields in the YAML schema to configure the actual Object Lock retention mode (Compliance/Governance) or duration (days).

Describe the solution you'd like

We should expand the spec.buckets schema in tenant-crd.yaml to support explicit versioning and full object lock configuration directly in the YAML:

spec:
  buckets:
    - name: secure-bucket
      versioning: true
      objectLock: true
      objectLockConfiguration:
        mode: Compliance # Compliance or Governance
        days: 30

Describe alternatives you've considered

Using manual post-install scripts or Kubernetes Jobs with mc/rc CLI to set retention periods over the S3 API.

Additional context

Adding this to the CRD will make bucket provisioning completely declarative and provide a true zero-touch bootstrap experience for new S3 Tenants.

[GatewayJ]

Thanks for the request. The implementation is available in #260 and will be usable after it is merged and included in an Operator release.
Before using the new fields, upgrade the Tenant CRD from the same Operator release. Add the bucket configuration under spec.buckets in the Tenant manifest:

apiVersion: rustfs.com/v1alpha1
kind: Tenant
metadata:
  name: rustfs-a
  namespace: storage
spec:
  # Existing Tenant configuration...

  buckets:
    - name: app-data
      region: us-east-1
      versioning: true
      objectLock: true
      objectLockConfiguration:
        mode: Compliance
        days: 30

Supported values:

• versioning: true enables S3 bucket versioning.
• objectLock: true enables Object Lock.
• objectLockConfiguration.mode accepts Governance or Compliance.
• objectLockConfiguration.days accepts values from 1 through 36500.
• Omitting objectLockConfiguration.state means Present.
• region is optional and is used when creating the bucket.
  Apply the Tenant manifest normally:

kubectl apply -f tenant.yaml

The Operator continuously reconciles these fields. Existing buckets are supported: the Operator reads the current configuration, enables versioning before Object Lock, applies the requested default retention, and verifies the result.
To remove an Operator-managed default retention rule:

spec:
  buckets:
    - name: app-data
      objectLock: true
      objectLockConfiguration:
        state: Absent

This removes the default retention rule while Object Lock remains enabled. S3 Object Lock stays enabled permanently after activation. Existing object versions keep their original retention settings.
If the bucket already has a different default retention rule that was configured outside the Operator, the Operator reports a conflict and preserves that rule.
You can inspect the reconciliation result with:

kubectl get tenant rustfs-a -n storage \
  -o jsonpath='{.status.provisioning.buckets[?(@.name=="app-data")]}{"\n"}'

The status reports the bucket state, versioning state, Object Lock state, reason, and message.