implementation of incident workflow and triggers

[jedelson-pagerduty]

This adds support for the new PagerDuty Incident Workflows (both Data Source and Resource) and Incident Workflow Triggers (Resource only) features. These are currently in Early Access and not available to all accounts.

Acceptance tests are gated behind an environment variable PAGERDUTY_ACC_INCIDENT_WORKFLOWS. This can be set to any value, but 1 is recommended for consistency with TF_ACC:

$ PAGERDUTY_ACC_INCIDENT_WORKFLOWS=1 make testacc TESTARGS="-run PagerDutyIncidentWorkflow"                              
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v -run PagerDutyIncidentWorkflow -timeout 120m
?       github.com/terraform-providers/terraform-provider-pagerduty     [no test files]
=== RUN   TestAccDataSourcePagerDutyIncidentWorkflow
--- PASS: TestAccDataSourcePagerDutyIncidentWorkflow (7.46s)
=== RUN   TestAccDataSourcePagerDutyIncidentWorkflow_Missing
--- PASS: TestAccDataSourcePagerDutyIncidentWorkflow_Missing (1.46s)
=== RUN   TestAccPagerDutyIncidentWorkflow_import
--- PASS: TestAccPagerDutyIncidentWorkflow_import (7.93s)
=== RUN   TestAccPagerDutyIncidentWorkflowTrigger_import
--- PASS: TestAccPagerDutyIncidentWorkflowTrigger_import (14.32s)
=== RUN   TestAccPagerDutyIncidentWorkflow_Basic
--- PASS: TestAccPagerDutyIncidentWorkflow_Basic (10.26s)
=== RUN   TestAccPagerDutyIncidentWorkflowTrigger_BadType
--- PASS: TestAccPagerDutyIncidentWorkflowTrigger_BadType (1.09s)
=== RUN   TestAccPagerDutyIncidentWorkflowTrigger_ConditionWithManualType
--- PASS: TestAccPagerDutyIncidentWorkflowTrigger_ConditionWithManualType (1.21s)
=== RUN   TestAccPagerDutyIncidentWorkflowTrigger_ConditionalTypeWithoutCondition
--- PASS: TestAccPagerDutyIncidentWorkflowTrigger_ConditionalTypeWithoutCondition (1.39s)
=== RUN   TestAccPagerDutyIncidentWorkflowTrigger_SubscribedToAllWithInvalidServices
--- PASS: TestAccPagerDutyIncidentWorkflowTrigger_SubscribedToAllWithInvalidServices (1.81s)
=== RUN   TestAccPagerDutyIncidentWorkflowTrigger_BasicManual
--- PASS: TestAccPagerDutyIncidentWorkflowTrigger_BasicManual (13.77s)
=== RUN   TestAccPagerDutyIncidentWorkflowTrigger_BasicConditionalAllServices
--- PASS: TestAccPagerDutyIncidentWorkflowTrigger_BasicConditionalAllServices (11.13s)
PASS
ok      github.com/terraform-providers/terraform-provider-pagerduty/pagerduty   72.205s

As mentioned in heimweh/go-pagerduty#104, I have tried to avoid the use of deprecated APIs which means these resources/datasources use slightly different patterns than the existing ones, e.g. CreateContext vs. Create. The same applies to the tests, where ProviderFactories is used instead of Providers. Refactoring existing resources/data sources/tests is a useful exercise but not in scope of this PR.

[pdecat]

Why not reuse the complete schema from the resource for the datasource too?
The resourcePagerDutyIncidentWorkflowRead() function should be directly reusable here too.

https://github.com/PagerDuty/terraform-provider-pagerduty/pull/596/files#diff-dfbdab15f4a4d80c9b6104498888bc2ed34951448a850d573c7e7541eae50367R26-R76

This would make the datasource more useful IMO, as just returning the name and description fields is pretty useless for terraform configuration.

Note: I'm posting this as I was recently confronted to the pagerduty_service datasource as I wanted to be able to check the status field of services, only to find out that datasource is pretty much useless:
https://github.com/PagerDuty/terraform-provider-pagerduty/blob/v2.6.5/pagerduty/data_source_pagerduty_service.go#L17-L26

Suggested change

	Schema: map[string]*schema.Schema{
	"name": {
	Type: schema.TypeString,
	Required: true,
	},
	"description": {
	Type: schema.TypeString,
	Computed: true,
	},
	},
	Schema: map[string]*schema.Schema{
	"name": {
	Type: schema.TypeString,
	Required: true,
	},
	"description": {
	Type: schema.TypeString,
	Computed: true,
	},
	},

[pdecat]

For an example of how it is done in the Google terraform provider, see: https://github.com/hashicorp/terraform-provider-google/blob/v4.45.0/google/data_source_cloud_run_service.go

[jedelson-pagerduty]

I can see how this would be useful in other cases, but in this particular context, I'm not sure what one would do with the embedded steps of the workflow if they were provided by the data source. Really the only use case for the data source is (as shown in the example in the documentation below) to reference an existing (presumably manually created) workflow by name when managing a trigger in Terraform.

This would make the datasource more useful IMO, as just returning the name and description fields is pretty useless for terraform configuration.

Agreed. Strictly speaking, all you need is the ID; it just promoted some better reuse of the flattenIncidentWorkflow function to have name and description in the schema.

The resourcePagerDutyIncidentWorkflowRead() function should be directly reusable here too.

Sure, but that would do an extra HTTP request. The workflow is already available at that point in the code path, no need to fetch it again. This is different than the Google Cloud Run since that API supports name-based addressing.

[imjaroiswebdev]

@jedelson-pagerduty Please check out the comments I left to continue with the approval after that

[imjaroiswebdev]

thank you for this great addition of Incident Workflows, and also for updating the provider implementations every time you had the opportunity to it 💪🏽 🎉