test: Ensures project withDefaultAlertsSettings works with import and introduce create_only plan modifier

[EspenAlbert]

Description

Link to any related issue(s): CLOUDP-302586 & #3103

Updated context:

• The API now returns with_default_alert_settings, before this was only set on create and never returned.
• This can impact users:

During Plan

• If the user did not define the attribute, the default value of true should match what the API returns, TODO: CHECK ME in a migration test
• If the user defined the attribute in their config during create and never made changes, there should be no plan changes, todo check in migration test
• If the user created the project and later changed the value, the API and the config will differ and they will see an error when they run a terraform plan, see the error message below.

The user will be forced to update their config to match the API value, otherwise they will get inconsistent result value.

During Update

Before this change, Terraform allowed updates to with_default_alert_settings, but now we will raise an error:

Error message:

│ Error: with_default_alerts_settings cannot be updated or set after import, remove it from the configuration or use state value.
│ 
│   with mongodbatlas_project.project,
│   on main.tf line 22, in resource "mongodbatlas_project" "project":
│   22: resource "mongodbatlas_project" "project" {
│ 
│ The current state value is true

• As soon as the user removes/updates the value, they will get No Plan Changes

During Import

Import works now due to the API change, and the experience will be the same as described in During Plan above

Type of change:

• Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
• New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
• Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
• This change requires a documentation update
• Documentation fix/enhancement

Required Checklist:

• I have signed the MongoDB CLA
• I have read the contributing guides
• I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
• I have added any necessary documentation (if appropriate)
• I have run make fmt and formatted my code
• If changes include deprecations or removals I have added appropriate changelog entries.
• If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

[github-actions]

APIx bot: a message has been sent to Docs Slack channel

[EspenAlbert]

The user will still get a plan change after import if they have set with_default_alert_settings=false in their config. But we don't have access to that information in the import

[maastha]

Since this is still a possibility, I'm thinking if we should even implement this fix. This sounds like it should be expected behavior that WithDefaultAlertsSettings will not be set during import and maybe something we can call out in our documentation instead.

I'd find it harder to explain to users why import shows an update if with_default_alert_settings=false in their config but works when it's true.

[marcosuma]

it just feels a workaround from an API limitation, have we reached out to the team owning this feature?

[EspenAlbert]

I understand is a create-only parameter that has a side effect of creating alert settings, but I'll check with upstream. Api Docs

[marcosuma]

@EspenAlbert nit: can we have a why in the summary section to explain the change? also let's hold this merge until we have a conversation with the upstream team (if we did, we should connect the CLOUDPs and understand the why on their side)

[kanchana-mongodb]

LGTM

[EspenAlbert]

Will get back to this on Wednesday

[maastha]

Can we add a comment on what this plan modifier does & why it's needed?

[github-actions]

This PR has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!

[EspenAlbert]

This test case is a bit different than usual, I tried to add comments, but let me know if anything is unclear.

[marcosuma]

@EspenAlbert let's hold on this one. I am not too convinced we are doing the right thing in adding more complexity to handle something like this. Let's chat in today's tech sync.