Fix Fleet Management pipeline unordered matchers

[johannaojeling]

The Fleet Management pipeline resource produces an inconsistent result if the specified matchers elements are not ordered, since the API response contains the elements sorted in ascending order. This PR addresses the issue by adapting the custom type ListOfPrometheusMatcherType with semantic equality so that the elements can be declared unordered.

Bug reproduction

Configuration:

terraform {
  required_providers {
    grafana = {
      source  = "grafana/grafana"
      version = ">= 3.22.0"
    }
  }
}

provider "grafana" {
  fleet_management_auth = "<AUTH>"
  fleet_management_url  = "<URL>"
}

resource "grafana_fleet_management_pipeline" "pipeline" {
  name     = "test_pipeline"
  contents = "// test"
  matchers = [
    "env=\"prod\"",
    "collector.os=\"linux\"",
  ]
}

Command:

terraform apply

Logs output:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # grafana_fleet_management_pipeline.pipeline will be created
  + resource "grafana_fleet_management_pipeline" "pipeline" {
      + contents = "// test"
      + enabled  = true
      + id       = (known after apply)
      + matchers = [
          + "env=\"prod\"",
          + "collector.os=\"linux\"",
        ]
      + name     = "test_pipeline"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

grafana_fleet_management_pipeline.pipeline: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to grafana_fleet_management_pipeline.pipeline, provider "provider[\"registry.terraform.io/grafana/grafana\"]" produced an unexpected
│ new value: .matchers[0]: was cty.StringVal("env=\"prod\""), but now cty.StringVal("collector.os=\"linux\"").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to grafana_fleet_management_pipeline.pipeline, provider "provider[\"registry.terraform.io/grafana/grafana\"]" produced an unexpected
│ new value: .matchers[1]: was cty.StringVal("collector.os=\"linux\""), but now cty.StringVal("env=\"prod\"").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

[github-actions]

In order to lower resource usage and have a faster runtime, PRs will not run Cloud tests automatically.
To do so, a Grafana Labs employee must trigger the cloud acceptance tests workflow manually.

[tpaschalis]

Does that mean that the ValidateAttribute method called implicitly here?

[johannaojeling]

Correct, when we implement the xattr.ValidateableAttribute interface, that will already have been called and the value validated once the semantic equality is checked. (It follows the docs examples for validation and semantic equality as well as Terraform provided custom type code.)

[tpaschalis]

LGTM with my (pretty limited) Terraform knowledge.