Update to terraform-plugin-framework 0.12 and fix import order

[pascal-hofmann]

Update to terraform-plugin-framework 0.12 and fix import order.

Description

• provider has been replaced by client in datasources and resources. This way we could also get rid of the internal.Provider interface.
• Deprecated things have been removed/replaced. See https://github.com/hashicorp/terraform-plugin-framework/releases/tag/v0.12.0

Related Issues

Motivation and Context

How Has This Been Tested?

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (improves code quality but has no user-facing effect)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation

Readiness Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[dimuon]

@pascal-hofmann , does it make sense to eliminate provider? It can be a placeholder for other info that we don't use at the moment but still can be handy at some point (e.g. provider version information, that is also mentioned at some examples). It looks like as an optimisation change that has a big chance to be reverted at some point. And the benefit of the removal is (IMO) not so significant.

[pascal-hofmann]

If we need more information we can always introduce a ProviderData struct and pass this as DataSourceData/ResourceData later on. (I do not like the circular dependency we had).

I try to avoid unneeded abstractions and layers, because they make reasoning about the code harder. With the great tooling and tests available, this will be quick to add once needed.

For now I think we should stick to the simple implementation introduced with this PR, which is aligned with the examples from:

• https://github.com/hashicorp/terraform-plugin-framework/blob/main/website/docs/plugin/framework/providers.mdx#configure-method
• https://github.com/hashicorp/terraform-plugin-framework/blob/main/website/docs/plugin/framework/data-sources/configure.mdx#define-data-source-configure-method
• https://github.com/hashicorp/terraform-plugin-framework/blob/main/website/docs/plugin/framework/resources/configure.mdx#define-resource-configure-method

[pascal-hofmann]

@dimuon Give me a shout if you want me to rebase https://github.com/dimuon/terraform-provider-ec/tree/feature/530/ec-deployment once this is merged.

[dimuon]

If we need more information we can always introduce a ProviderData struct and pass this as DataSourceData/ResourceData later on. (I do not like the circular dependency we had).

I try to avoid unneeded abstractions and layers, because they make reasoning about the code harder. With the great tooling and tests available, this will be quick to add once needed.

For now I think we should stick to the simple implementation introduced with this PR, which is aligned with the examples from:

* https://github.com/hashicorp/terraform-plugin-framework/blob/main/website/docs/plugin/framework/providers.mdx#configure-method

* https://github.com/hashicorp/terraform-plugin-framework/blob/main/website/docs/plugin/framework/data-sources/configure.mdx#define-data-source-configure-method

* https://github.com/hashicorp/terraform-plugin-framework/blob/main/website/docs/plugin/framework/resources/configure.mdx#define-resource-configure-method

if it were a circular dependency it won't compile I guess :). Also the first link mention both approaches (provider and client).
Anyway, if you feel more comfortable with the approach, go forward - it's not a big deal to either keep it or remove it. We can bring it back later on if needed.

[dimuon]

LGTM

[dimuon]

@dimuon Give me a shout if you want me to rebase https://github.com/dimuon/terraform-provider-ec/tree/feature/530/ec-deployment once this is merged.

@pascal-hofmann thank you for the help, mate!