Fix service datasource returning null due to failing system lookups

[derek-etherton-opslevel]

Issues

The opslevel_service data source was completely broken - returning null for all fields (name, description, etc.) in provider versions > v1.4.0.

Impact: 100% failure rate. Every usage of data "opslevel_service" would return null for all fields, regardless of whether the service had a parent system or not.

Root causes:

1. Wrong GraphQL field - Code was calling service.GetSystem() which queries a non-existent system field, but the API has a parent field
2. Early return on error - When the GraphQL query failed, the function would return immediately without saving any state
3. Missing diagnostic appends - Local diags variable was never appended to resp.Diagnostics, so errors were missing

Solution

Changed the Read() function in opslevel/datasource_opslevel_service.go to:

• Use service.Parent directly instead of calling GetSystem() (avoids the GraphQL error)
• Continue processing even if optional fields like system/parent fail to load (saves core service data)
• Properly append all diagnostics to the response

This approach ensures users get their service data (name, description, etc.) even if optional parent system information isn't available.

Testing

Added integration test tests/remote/datasource_service.tftest.hcl that validates all service fields are populated.

To manually test:

export OPSLEVEL_API_TOKEN="your-token"
task test-integration -- -filter=datasource_service.tftest.hcl

Expected: Success! 1 passed, 0 failed.

You can also test with actual Terraform config:

data "opslevel_service" "test" {
  id = "your-service-id"
}

output "name" {
  value = data.opslevel_service.test.name  # Should not be null
}

output "description" {
  value = data.opslevel_service.test.description  # Should not be null
}

[derek-etherton-opslevel]

apparently opslevel-go's GetSystem tries to retrieve system on Service, but the field is parent 😢

[derek-etherton-opslevel]

couple minor changes here with error handling:

1. making sure diags is always actually recorded (sometimes we'd just overwrite it w/ the next one)
2. remove early returns when fetching some "extra" data fails. As long as we're recording appropriate errors, letting partial success through should make future bugs less catastrophic