Refer to smtp_config by ID

[cimnine]

This updates the terraform provider to refer to the SMTP Configuration by their IDs. This is a breaking change! Previous SMTP configs need to be removed from the state and re-imported with their proper resource ID.

Fixes #180

Todo

• [ ] Fix import acceptance test

Definition of Ready

• [x] Short description of the feature/issue is added in the pr description
• [x] PR is linked to the corresponding user story
• [ ] Acceptance criteria are met
• [ ] All open todos and follow ups are defined in a new ticket and justified
• [ ] Deviations from the acceptance criteria and design are agreed with the PO and documented.
• [x] No debug or dead code
• [x] My code has no repetitions
• [x] All non-functional requirements are met
• [ ] The generic lifecycle acceptance test passes for affected resources.
• [x] Examples are up-to-date and meaningful. The provider version is incremented.
• [ ] Docs are generated.
• [x] Code is generated where possible.

[cimnine]

The test currently fails as follows:

=== RUN   TestAccSMTPConfig
=== PAUSE TestAccSMTPConfig
=== CONT  TestAccSMTPConfig
    lifecyletest.go:73: Step 5/7 error running import: exit status 1

        Error: Cannot import non-existent remote object

        While attempting to import an existing object to
        "zitadel_smtp_config.default", the provider detected that no object exists
        with the given id. Only pre-existing objects can be imported; check that the
        id is correct and that it is associated with the provider's configured region
        or endpoint, or use "terraform apply" to create a new remote object for this
        resource.

--- FAIL: TestAccSMTPConfig (4.62s)

I'm not sure how to proceed. There is probably no default SMTP config anymore, so to import a default SMTP config, one would have to be created beforehand. Is this the correct assumption and how to do that?

[cimnine]

For reference: Via Discord Migual A. C suggested that this resource should also activate the SMTP configuration:

For your code I'd add the followint to the smtpconfig/funcs.go to activate the provider after it has been created:

    _, err = client.ActivateSMTPConfig(ctx, &admin.ActivateSMTPConfigRequest{Id: resp.Id})
    if err != nil {
        return diag.Errorf("failed to activate smtp config: %v", err)
    }

However, I don't believe that this is a good idea:

I believe the activate part should be a new independent resource. Otherwise, if there are multiple parallel configurations, it will never be deterministic which configuration is currently active.

There could also be an is_active flag on the zitadel_smtp_config resource. But it would be hard to enforce that only one zitadel_smtp_config defines is_active = true:

The benefit of an independent resource compared to an is_active flag (or similar) is, that with the resource we can use the internal terraform ID to ensure that there is only one zitadel_active_smtp_config (or whatever the name shall be).