feat: Adds new `mongodbatlas_control_plane_ip_addresses` data source

[AgustinBettati]

Description

Link to any related issue(s): CLOUDP-250897

Defines a new data source for the following endpoint: https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Root/operation/returnAllControlPlaneIPAddresses

Example API response and resulting tf state

``` ---[ REQUEST ]--------------------------------------- GET /api/atlas/v2/unauth/controlPlaneIPAddresses HTTP/1.1 ---[ RESPONSE ]-------------------------------------- HTTP/2.0 200 OK { "inbound": { "aws": { "ap-southeast-1": [], "eu-west-1": [], }, "azure": { "australiaeast": [], "eastus2": [], }, "gcp": { "europe-west1": [], } }, "outbound": { "aws": { "ap-southeast-1": [ "54.66.0.167/32", "54.253.68.72/32" ], "eu-west-1": [ "54.78.184.167/32", "52.210.32.198/32" ], "us-east-1": [ "3.90.117.229/32", "3.224.224.200/32" ] }, "azure": { "australiaeast": [ "20.53.129.178/32" ], "eastus2": [ "20.94.32.37/32" ] }, "gcp": { "europe-west1": [ "34.78.42.14/32" ], "us-east4": [ "34.85.218.41/32" ] } } } ``` Resulting terraform state: ``` { "mode": "data", "type": "mongodbatlas_control_plane_ip_addresses", "name": "test", "provider": "provider[\"registry.terraform.io/mongodb/mongodbatlas\"]", "instances": [ { "schema_version": 0, "attributes": { "inbound": { "aws": { "ap-southeast-1": [], "eu-west-1": [] }, "azure": { "australiaeast": [], "eastus2": [], "westeurope": [] }, "gcp": { "europe-west1": [] } }, "outbound": { "aws": { "ap-southeast-1": [ "54.66.0.167/32", "54.253.68.72/32" ], "eu-west-1": [ "54.78.184.167/32", "52.210.32.198/32" ], "us-east-1": [ "3.90.117.229/32", "3.224.224.200/32" ] }, "azure": { "australiaeast": [ "20.53.129.178/32" ], "eastus2": [ "20.94.32.37/32" ] }, "gcp": { "europe-west1": [ "34.78.42.14/32" ], "us-east4": [ "34.85.218.41/32" ] } } } ... ```

Type of change:

• [ ] Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
• [x] 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.
• [x] This change requires a documentation update
• [ ] Documentation fix/enhancement

Required Checklist:

• [x] I have signed the MongoDB CLA
• [x] I have read the contributing guides
• [x] I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• [x] I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
• [x] I have added any necessary documentation (if appropriate)
• [x] I have run make fmt and formatted my code
• [x] If changes include deprecations or removals, I defined an isolated PR with a relevant title as it will be used in the auto-generated changelog.
• [x] 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[bot]]

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

[marcosuma]

Great job @AgustinBettati - did you use the automation to create the scaffolding?

Also +1 to @maastha sentiment, curious if we can come up with a smaller PR approach next time: biggest challenge is to make sure we don't miss smaller bugs such as misspells

[AgustinBettati]

did you use the automation to create the scaffolding?

@marcosuma yes for this case used initial file scaffolding, schema and model scaffolding, and then documentation autogeneration. Included some fixes to these tools along the way, related to our new file naming convention aligned with our latest resource push-based log export.

could this PR have been split into smaller ones?

@maastha yes I see how this got a little to big as many small changes were included. Would keep fixes related to scaffolding + setup in CI as separate PR to avoid additional noise to the actual production code. Thanks for the input and sorry if the review was a challenge here.

[maastha]

@maastha yes I see how this got a little to big as many small changes were included. Would keep fixes related to scaffolding + setup in CI as separate PR to avoid additional noise to the actual production code. Thanks for the input and sorry if the review was a challenge here.

no problem! Also, just FYI we do have a possible approach to split new feature PRs captured in our TF best practices doc, happy to discuss any alternatives/your general inputs there:)