adopt internal/ layout structure

[displague]

The number of files in equinix/ has been expanding with recent additions. The developer experience can be improved by compartmentalizing resources into an alternate structure. This practice has become more popular in the past year or so.

Proposed structure:

• equinix/provider.go By maintaining the "provider" package, downstream tooling such as Pulumi, Kubeform, Crossplane, and the OpenShift IPI driver (under development, paused) may continue to import the project
• internal/services/metal/device/schema.go This would combine all schemas into a single file. This is a pattern found in Kubebuilder {resourcename}_types.go files for a single resource. In Kubebuilder all resources reside in their own file, packaged by API version.
  Crossplane follows a similar pattern with an extra service path (https://github.com/crossplane-contrib/provider-tf-equinix-metal/tree/main/apis/connection/v1alpha1). An interesting distinction about Crossplane's pattern is that the schema symbols are exported. This may be a requirement for some downstream tooling (I haven't researched or identified this).
• internal/services/metal/device/resource.go
• internal/services/metal/device/datasource.go
• internal/services/networkedge/device/resource.go
• other common files should flow naturally by refactoring the single resource files today. Each resource could, for example, include flatteners, expanders, converters, and other helpers.
• internal/migrationtool/
• A matching _test.go for each file

Considerations:

• removing exported symbols from equinix/ is a breaking change from a Go and user perspective. I believe we can safely assert from the aforementioned consumers, that most if not all Go consumers are interested in the Provider type, and nothing else.
• Linode's provider puts the HCL templates used during E2E testing into a separate folder and file for each template. A template builder pattern allows for a functional, chaining, approach to modifying the test template.

Inspiration:

• https://github.com/linode/terraform-provider-linode/tree/main/linode (the Equinix provider offers multiple service trees, in the proposed paths above, the folder is one level deeper to distinguish services)
• https://github.com/hashicorp/terraform-provider-aws/tree/main/internal/service (this level of break-up seems unnecessary for the size of the Equinix provider.)
• https://github.com/hashicorp/terraform-provider-azurerm/tree/main/internal/services (The internal/services pattern could be useful in the Equinix provider to keep service implementation code away from, migration tool code, for example.)

[ocobles]

Are we ready to close this issue or should it remain open until all resources are fully migrated into internal? I have created another issue to track resources migration to framework where we force move them to internal during migration https://github.com/equinix/terraform-provider-equinix/issues/612

[displague]

Moving to internal/ could be done ahead of Framework migration which can be trickier. I think we should leave this open until the resources are moved to internal and the teams supporting this work should take this step before Framework migration.