Migrate the provider from the legacy SDKv2 plugin to the newer terraform plugin framework

[stefannica]

Migrate provider to Terraform Plugin Framework while preserving the API backwards compatibility.

Why

• the legacy SDKv2 plugin doesn't support modern features like dealing with sub-nested object data types
• SDKv2 is stable but largely in maintenance; new capabilities and fixes land in terraform-plugin-framework
• The framework’s type system and lifecycle hooks let us eliminate the JSON double-encoding that caused perpetual plan diffs. This improves trust in Terraform plans and reduces noisy churn in CI.
• This sets the groundwork for future features (richer validation, better plan semantics, additional resources)

Scope

• Provider fully migrated to terraform-plugin-framework.
• All resources/data sources migrated, with emphasis on zenml_service_connector parity and behavior.
• Dependencies updated to a compatibility-verified set.
• Preserved the user-facing API (resources, data sources, attributes).

Backward Compatibility

• Resource and data source names/attributes preserved.
• Behavior preserved where it matters:
  • verify defaults to enabled if unset, matching pre-migration intent
    (verification performed before create/update).
  • JSON/string configuration behavior now consistently matches the old
    provider’s effective behavior (no double-encoding).
  • the provider throws warnings if configuration attributes are not reflected back by the zenml server

Developer Notes

• Verification retry logic mirrors SDKv2 semantics using
  terraform-plugin-sdk/v2/helper/retry with framework contexts.
• Timeouts integrated via terraform-plugin-framework-timeouts.
• Diagnostics leverage framework path.Root and tflog masking for
  credentials.

Testing

• go build and unit tests pass with the pinned dependency versions.
• Acceptance-style tests were migrated to the new testing framework
  and updated to reflect JSON and verification behavior.

Risks and Mitigations

• Framework/runtime version drift:
  • Pinned to a known-good combination to avoid interface mismatches.
• Plan-time validation differences vs. SDKv2:
  • Validators skip checks when attributes are unknown/empty during plan,
    aligning with conditional expressions and interpolation timing.
• ZenML server may mutate stack component / service connector configuration attributes
  • Attributes in the TF configuration that are not reflected back by the server are always kept and warnings are shown instead. This avoids false drift.
  • Attributes in the zenml server that have different values than those in the TF configuration are not applied during Create/Update to avoid inconsistency errors. Warnings are shown but false drift may be triggered.

Upgrade Impact for Users

• No configuration changes required.
• If you previously relied on non-string configuration types,
  switch to explicit strings (or wrap with jsonencode(...) as needed).

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}