Add ActionChecks

[YakDriver]

Description

NOTE: The Use modern Go commit adds about 400 lines of modern Go cleanup. I can split that from these changes if you prefer.

This PR adds ActionChecks - a new testing capability that validates progress messages from Terraform actions during test execution.

New ActionChecks framework following the same patterns as existing StateChecks and PlanChecks:

• TestCheckProgressMessageContains() - verify messages contain expected content
• TestCheckProgressMessageCount() - verify expected number of messages
• TestCheckProgressMessageSequence() - verify messages appear in expected order

Provider protocol interception to capture action progress messages in real-time:

• Wraps both tfprotov5 and tfprotov6 providers during test execution
• Intercepts InvokeAction calls to capture resp.SendProgress() messages
• Thread-safe progress message storage and retrieval

Integration with TestStep:

• New ActionChecks []actioncheck.ActionCheck field in TestStep
• Automatic progress capture when ActionChecks are present
• Validation runs after test step completion

Usage example:

resource.TestStep{
    Config: actionConfig,
    ActionChecks: []actioncheck.ActionCheck{
        resource.TestCheckProgressMessageContains("aws_lambda_invoke.test", "invoked successfully"),
        resource.TestCheckProgressMessageCount("aws_lambda_invoke.test", 2),
    },
}

This enables testing of action implementations like AWS Lambda invoke, CloudFront invalidation, etc. to verify they produce expected progress output for users.

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

[SBGoods]

Thanks for the contribution @YakDriver, I like the overall concept of using interceptors to capture progress messages. I have a couple of comments regarding overall design and some of the functionality.

[SBGoods]

For newer checks, we would prefer the functions to be in the same file where it's struct is defined for readability. This also helps distinguish the checks by package name:

 actioncheck.TestCheckProgressMessageCount("framework_modify_file_action", 2),

[SBGoods]

Suggested change

	func TestCheckProgressMessageContains(actionName, expectedContent string) actioncheck.ActionCheck {
	func ExpectProgressMessageContains(actionName, expectedContent string) actioncheck.ActionCheck {

[SBGoods]

Suggested change

	func TestCheckProgressMessageCount(actionName string, expectedCount int) actioncheck.ActionCheck {
	func ExpectProgressMessageCount(actionName string, expectedCount int) actioncheck.ActionCheck {

[SBGoods]

Suggested change

	func TestCheckProgressMessageSequence(actionName string, expectedSequence []string) actioncheck.ActionCheck {
	func ExpectProgressMessageSequence(actionName string, expectedSequence []string) actioncheck.ActionCheck {

[SBGoods]

Suggested change

	resource.TestCheckProgressMessageContains("aws_lambda_invoke.test", "Lambda function logs:"),
	resource.TestCheckProgressMessageContains("aws_lambda_invoke", "Lambda function logs:"),

The examples as written do not work because the provider does not have access to the alias name so you can only reference messages by action type name.

[SBGoods]

Suggested change

	resource.TestCheckProgressMessageSequence("aws_lambda_invoke.test", []string{
	resource.TestCheckProgressMessageSequence("aws_lambda_invoke", []string{

[SBGoods]

Really like this comment clarifying the source of the progress messages!

[SBGoods]

Right now, if the provider developer mistypes the action name in the check or if the expected action never produces any progress messages, the check will still pass without an error.

I think that we need to pass the entire map of messages from ProcessCapture into the CheckActionRequest so that each action check can throw an error if the action type name doesn't exist in the map.

[SBGoods]

nit: I wonder if the interface name should make it clear that these checks assert against intercepted provider messages rather than a standard Terraform artifact. Maybe there could be a future where there is a terraform-produced artifact for Actions and we would like a different interface for those types of checks? I don't have a strong opinion on this right now 🤔

[SBGoods]

I really like having this flag for process capture here, it helps reduce the performance cost of the interceptors.