add serverless project import

[graphaelli]

Description

enable serverless project import with terraform import

Related Issues

closes #918

Motivation and Context

Allows management of existing projects.

How Has This Been Tested?

• updated unit and acceptance tests
• used with dev_overrides to import observability and elasticsearch projects manually

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

Assisted by Cursor AI.

[graphaelli]

This fails with product types because they are not in a stable order. There is already handling for order insensitive equality in

terraform-provider-ec/ec/internal/gen/serverless/resource_security_project/product_types_list_type.go

Line 140 in 6b7a1bf

func (v ProductTypesListValue) ListSemanticEquals(ctx context.Context, otherV basetypes.ListValuable) (bool, diag.Diagnostics) {

but that's not called during import state verification.

@norrietaylor since you implemented this originally, thoughts on how to resolve this? Why is ListSemanticEquals separate from Equal? Can we sort the product lines as returned from the api or is the order significant elsewhere?

[tobio]

Does using their plancheck interface take semantic equality into account (IIUC it should since it's just asserting there's an empty plan)

				ImportPlanChecks: resource.ImportPlanChecks{
					PreApply: []plancheck.PlanCheck{
						plancheck.ExpectEmptyPlan(),
					},
				},

Why is ListSemanticEquals separate from Equal?

That's what the Terraform framework wants. Semantically equal values will be substituted by the prior value during plan/apply and so won't trigger errors due to inconsistent state.

Can we sort the product lines as returned from the api or is the order significant elsewhere?

We can, but we're then adding a bunch of code to workaround a test framework limitation which isn't ideal. I'd be surprised if we can't implement adequate validation via ImportPlanChecks

[graphaelli]

Thanks @tobio. Do I understand correctly that just checking that there is an empty plan is the sufficient check? I've pushed a214fe4 with that change

[tobio]

Sorry for the late reply, yep an empty plan should be the equivalent of what ImportStateVerify accomplishes.