Allow setting `max_versions` in `stackit_secretsmanager_instance` resource for dynamic numbers of instances

[alexzimmer96]

Problem description

Currently, it is not possible to set the max_versions configuration for a Secrets Manager instance during creation. The reasons for this have already been discussed in #965. However, there are significant limitations when creating multiple Secrets Manager instances that have not yet been addressed in that discussion.

We use a partitioning approach to split secrets into smaller units, each with its own access configuration. To keep the infrastructure maintainable, we manage all these instances within a single Terraform configuration using for_each.

Since the stackit_secretsmanager_instance resource does not support max_versions, we would theoretically need to use the HashiCorp Vault provider as a workaround. However, because each Secrets Manager instance requires its own set of credentials, we would have to dynamically create x user credentials and then create x provider configurations to match the x instances created via for_each.

Terraform does not support dynamic provider configuration, making it impossible to automate the max_versions setup for a dynamic number of instances.

locals {
  partitions = ["partition-1", "partition-2"]
}

resource "stackit_secretsmanager_instance" "secret_manager_partitions" {
  for_each   = toset(local.partitions)
  project_id = "xxx"
  name       = each.key
}

// Requirement: Set max_versions = 5 for all instances created above.
// Current blocker: This would require dynamic generation of users for all secrets manager, 
// followed by a dynamic vault provider per user, which is natively impossible in Terraform.

Proposed solution

Allow setting the max_versions parameter directly within the stackit_secretsmanager_instance resource or via a dedicated resource that does not require dynamic provider configuration.

Alternative solutions (optional)

The core reason we rely on this partitioning mechanism is that the STACKIT Secrets Manager currently provides no way to limit user access based on secret paths. Access is only managed via read and read+write permissions per instance.

If path-based access control were implemented (e.g., through compatibility with the Vault /sys/policy API), the need for creating multiple instances for partitioning would be significantly reduced for our use-case. However, there might be other scenarios where instance-level partitioning remains a requirement.