fix: Treat 404 as success on resource delete operations - #4784

Description

Deleting a resource that is already gone from Atlas returned 404 and failed the whole run. The delete had already achieved its goal, so this is success, not failure, matching the HashiCorp recommendation for resource deletes.

Follow-up of #4777, which fixed mongodbatlas_database_user and added the shared helper (internal/common/deletenotfound.IsNotFound). This PR applies the same pattern to all remaining hand-written resources, and replaces ad-hoc 404 checks (manual validate.StatusNotFound blocks and string-matching) with the helper. The tolerated 404 case is logged so it can be observed in production.

Affected resources:

mongodbatlas_advanced_cluster, mongodbatlas_alert_configuration, mongodbatlas_auditing, mongodbatlas_backup_compliance_policy, mongodbatlas_cloud_backup_schedule, mongodbatlas_cloud_backup_snapshot, mongodbatlas_cloud_backup_snapshot_export_bucket, mongodbatlas_cloud_backup_snapshot_restore_job, mongodbatlas_cloud_provider_access_setup, mongodbatlas_cluster, mongodbatlas_cluster_outage_simulation, mongodbatlas_custom_db_role, mongodbatlas_database_user, mongodbatlas_encryption_at_rest_private_endpoint, mongodbatlas_event_trigger, mongodbatlas_federated_database_instance, mongodbatlas_federated_query_limit, mongodbatlas_federated_settings_identity_provider, mongodbatlas_federated_settings_org_config, mongodbatlas_federated_settings_org_role_mapping, mongodbatlas_flex_cluster, mongodbatlas_global_cluster_config, mongodbatlas_ldap_configuration, mongodbatlas_maintenance_window, mongodbatlas_network_peering, mongodbatlas_online_archive, mongodbatlas_organization, mongodbatlas_org_invitation, mongodbatlas_privatelink_endpoint, mongodbatlas_privatelink_endpoint_service, mongodbatlas_project, mongodbatlas_project_invitation, mongodbatlas_project_ip_access_list, mongodbatlas_project_service_account_access_list_entry, mongodbatlas_resource_policy, mongodbatlas_search_deployment, mongodbatlas_search_index, mongodbatlas_serverless_instance, mongodbatlas_service_account_access_list_entry, mongodbatlas_stream_instance, mongodbatlas_stream_privatelink_endpoint, mongodbatlas_stream_processor, mongodbatlas_stream_workspace, mongodbatlas_team_project_assignment

Not changed, on purpose:

• No API call in delete: mongodbatlas_x509_authentication_database_user, mongodbatlas_ldap_verify, mongodbatlas_cloud_backup_snapshot_export_job
• Delete goes through an update/toggle API, not a resource delete: mongodbatlas_custom_dns_configuration_cluster_aws, mongodbatlas_encryption_at_rest, mongodbatlas_private_endpoint_regional_mode
• Already treat 404 as success (poll/retry swallows it): mongodbatlas_network_container, mongodbatlas_team, mongodbatlas_stream_connection
• Legacy v1 SDK delete returns no HTTP response, so the guard cannot be applied: mongodbatlas_third_party_integration
• Pre-existing bug kept as-is to avoid new error surface (only errors on 404 and swallows other errors); will be analyzed separately, similar to CLOUDP-437881: mongodbatlas_mongodb_employee_access_grant

Verified against the dev environment that a delete of a made-up resource under a real parent returns 404 for the affected resources above. Exceptions observed:

• Org API key resources (mongodbatlas_api_key, mongodbatlas_project_api_key, mongodbatlas_access_list_api_key, mongodbatlas_api_key_project_assignment): the API returns 400 API_KEY_NOT_FOUND instead of 404 for a missing key (even on GET), so delete behavior does not change there. The guard is kept so these resources automatically treat the delete as success when/if the API is fixed.
• mongodbatlas_push_based_log_export (deprecated): returns 400 PUSH_BASED_LOG_EXPORT_ALREADY_UNCONFIGURED when already unconfigured, so the guard does not change its behavior.
• mongodbatlas_maintenance_window: resetting an unconfigured window returns 204, already a success.
• mongodbatlas_stream_privatelink_endpoint: delete is accepted asynchronously with 202.

Link to any related issue(s):

• [Bug]: mongodbatlas_database_user Delete fails on USER_NOT_FOUND #4656
• CLOUDP-453232

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 fix and verified 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

A 404 can also mean a mistaken project ID or credentials scoped differently; previously the error surfaced that, now the resource is silently dropped from state and the mistake appears later as drift. This trade-off was accepted in the ticket triage ("we only turn failure into success operations"), and the tflog line makes the tolerated case observable.

Autogen resources already treat a 404 on delete as success by construction.