Provider lacks built-in retry/backoff for HTTP 429 rate limit responses

[knowlesy]

Description

The CloudConnexa provider has no mechanism to handle HTTP 429 (Too Many Requests) responses from the API. When running Terraform with any parallelism greater than 1, API rate limits are frequently hit, causing resources to fail mid-plan.

Current Behavior

• API returns HTTP 429 → Terraform immediately fails the resource operation
• Users are forced to set -parallelism=1 to avoid rate limits, significantly increasing plan/apply times
• No retry or backoff logic exists anywhere in the provider
• The underlying cloudconnexa-go-client SDK has token-bucket rate limiters but does not retry on 429 responses

Expected Behavior

The provider should automatically retry requests that receive HTTP 429 (and 503) responses using exponential backoff with jitter, transparent to the user.

Impact

• Any pipeline running multiple resources in parallel is unreliable
• Large infrastructures with many CloudConnexa resources cannot be managed efficiently
• Users have no provider-level workaround other than serializing all operations

Environment

• Terraform Provider: OpenVPN/cloudconnexa
• Affected versions: all current releases
• Reproducible with: any terraform plan or terraform apply with multiple CloudConnexa resources at default parallelism

Fix

PR #202 (feat/rate-limit-retry) implements:

• Automatic retry with exponential backoff (1s base, 2x multiplier, 30s cap, ±20% jitter) on 429 and 503
• Configurable max_retries provider attribute (default 5, env CLOUDCONNEXA_MAX_RETRIES, set 0 to disable)
• Applied to all resources and data sources
• 14 unit tests covering retry logic
• Zero breaking changes for existing users