[Stacks Actions] Add Action Invocation Protocol Support

[mutahhir]

Description

This PR updates the Stacks protobuf protocols to support Action Invocation messages. It regenerates protobuf code for dependencies and introduces new message types for communicating action invocations between Terraform, TFC Agent, and Atlas.

Key protocol changes:

• Updated protobuf schema definitions for action invocations
• Regenerated Go code from .proto files
• Added message types for action invocation lifecycle events
• Protocol version remains at 3 (backward compatible additions)

This is a foundational change that establishes the communication layer. The actual implementation logic that uses these protocols comes in subsequent PRs.

RFC: https://hermes.hashicorp.services/document/1qNke5ZCTNMQIw-rPietiHbHlV0zJELDtDftTeN2RjVc
Jira: https://hashicorp.atlassian.net/browse/TF-33014

Related PRs

This PR is part of the Stacks Actions - Lifecycle Triggered Action Invocations project.

Terraform:

• [Stacks Actions] Add Action Invocation Protocol Support #38051 ← This PR
• [Stacks Actions] Implement Plan Action Invocations mutahhir/terraform#3
• [Stacks Actions] Implement Deferred Action Invocations in Plan mutahhir/terraform#5
• [Stacks Actions] Apply SRO mutahhir/terraform#4

TFC Agent:

• hashicorp/tfc-agent#1304
• hashicorp/tfc-agent#1327
• hashicorp/tfc-agent#1336

Atlas:

• hashicorp/atlas#26691

References:

• RFC: https://hermes.hashicorp.services/document/1qNke5ZCTNMQIw-rPietiHbHlV0zJELDtDftTeN2RjVc
• JIRA: TF-33014

Target Release

1.15.x

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.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[DanielMSchmidt]

Great work 🎉 Thank you also for the overview / context on all the PRs. I found an issue that will probably track through the other PRs, but I'll look at them as well to give you as much feedback as possible 👍

[DanielMSchmidt]

The status is insufficient I think. The same action could be triggered by multiple lifecycle trigger events and will then run once per event. E.g.

action "aws_cloudfront_cache_clear" "lb" { ... }

resource "aws_instance" "backend" {
  ...
  lifecycle {
    action_trigger {
      events = [after_create, after_update]
      actions = [action.aws_cloudfront_cache_clear.lb]
    }
  }
}

resource "aws_instance" "frontend" {
   ...
  lifecycle {
    action_trigger {
      events = [after_create, after_update]
      actions = [action.aws_cloudfront_cache_clear.lb]
    }
  }
}

In this example action.aws_cloudfront_cache_clear would run two times, once after aws_instance.backend and once after aws_instance.frontend. The ActionInvocationInstanceInStackAddr is not uniquely identifying an invocation of an action, but an instance of an action. So a declaration of what might happen vs a specific instance of what is happening. So you need both the ActionInvocationInstanceInStackAddr as well as

oneof action_trigger {
          LifecycleActionTrigger lifecycle_action_trigger = 6;
          InvokeActionTrigger invoke_action_trigger = 7;
      }

To identify a single action that is running. Same goes for the ActionInvocationProgress message, plans.ActionInvocationInstance already has this info so you probably don't need it twice for PlanActionInvocationPlanned

[mutahhir]

What a catch!