feat: Update Search Deployment Resource

[sivaram-mongodb]

Proposed changes

• Upgraded Atlas SDK from v20231115014 to v20250312012
• Updated API method names to match new SDK (GetClusterSearchDeployment, etc.)
• Added EncryptionAtRestProvider read-only property
• Improved deleted resource detection via empty Specs array check
• Enhanced ID preservation in model mapping
• Updated unit tests for new SDK version
• Schema validation improvements (minItems/maxItems for Specs)

cfn-testing

Published to AWS private registry

Stack Testing

Atlas - Before Creation

Atlas - After Creation

Jira ticket: CLOUDP-369807

Please include a summary of the fix/feature/change, including any relevant motivation and context.

Link to any related issue(s):

Type of change:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as
  expected)
• This change requires a documentation update
• 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.

Manual QA performed:

• cfn invoke for each of CRUDL/cfn test
• Updated resource in example
• Published to AWS private registry
• Used the template in example to create and update a stack in AWS
• Deleted stack to ensure resources are deleted
• Created multiple resources in same stack
• Validated in Atlas UI
• Included screenshots

Required Checklist:

• I have signed the MongoDB CLA
• I have added tests that prove my fix is effective or that my feature works
• I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• I have added any necessary documentation (if appropriate)
• I have run make fmt and formatted my code
• For CFN Resources: I have released by changes in the private registry and proved by change
  works in Atlas

Further comments

[semgrep-code-mongodb]

Semgrep identified an issue in your code:
Variable resp is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

To resolve this comment:

✨ Commit Assistant Fix Suggestion

1. Add a nil check for resp before accessing its fields inside the if err != nil block.
2. Update the first inner if condition to if targetState == constants.DeletedState && resp != nil && resp.StatusCode == http.StatusBadRequest && strings.Contains(err.Error(), SearchDeploymentDoesNotExistsError).
3. Update the final error return to also ensure resp is not nil if it will be dereferenced, for example: return progressevent.GetFailedEventByResponse(err.Error(), resp) becomes return progressevent.GetFailedEventByResponse(err.Error(), resp) if that function handles nil safely, otherwise check if resp != nil { ... } else { ... }.

This change prevents a potential panic if resp is nil by ensuring the code only accesses resp.StatusCode when resp is not nil.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by invalid-usage-of-modified-variable.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

• Fix the code
• Reply /fp $reason (if security gap doesn’t exist)
• Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
• Reply /other $reason (e.g., test-only)

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[maastha]

LGTM once semgrep comment is addressed

@sivaram-mongodb can you also add a link to the test stack in the JIRA ticket?