feat: Enable per-component restart and update within workloads

[Aditya1404Sal]

Feature or Problem

This PR adds component-level lifecycle management to the wasmcloud runtime, enabling granular control over individual components within a workload without requiring full workload restarts. Previously, any component update or state change required restarting the entire workload, causing unnecessary downtime for unaffected components.

Key capabilities added:

• Component-level start/stop operations: Start or stop specific components by name or ID within a running workload
• Component state tracking: Components now track their lifecycle state (Starting, Running, Stopped, Reconciling, Error, Stopping)
• Component naming: Optional user-defined names for stable component identification across updates (Kubernetes-style naming)
• Intelligent component updates: workload_update automatically detects which components changed and updates only those
• Dependency re-linking: When a component is updated, all dependent components are automatically re-linked in topological order to use the new code

Related Issues

Release Information

next

Consumer Impact

Breaking Changes: None - this is a backwards-compatible addition.

API Additions:

• WorkloadStartRequest now accepts optional component_ids filter to start specific components
• WorkloadStopRequest now accepts optional component_ids filter to stop specific components
• WorkloadUpdateRequest added - takes a Workload spec and updates only changed components
• WorkloadStatusResponse now includes ComponentInfo list with per-component state (id, name, state, message)
• Component type now has optional name field for stable identification

Runtime Behavior Changes:

• Components stopped via component_ids remain in memory with Stopped state (can be restarted quickly)
• Component updates cascade: if component A depends on B which depends on C, updating C automatically re-links both B and A
• HTTP handler caches are automatically refreshed when components are re-linked

Testing

Unit Test(s)

None

Acceptance or Integration

Will commit soon

Manual Verification

tested it in an integration test setup, locally

[lxfontes]

I don't think we'd want this behaviour at the protobuf / clustered level. maybe at the wash engine level only ⚖️ ( for embedding / wash dev ).

Following Kubernetes / distributed-systems principles, "Restarts" are "Redeploys" by design for a few key reasons:

• Immutability: Like Kubernetes Pods, Workloads are immutable
• Orchestration: The host is never alone (besides embedding), there is always a Cluster Orchestrator taking care of moving workloads around
• Abstraction: It's ok to schedule Workloads, but users are better served using WorkloadReplicaSet or WorkloadDeployment which take into consideration fault domains

This "update-in-place" behavior is present in wasmcloud v1 + wadm and caused many outages / deploy issues and latency due to extra wrpc/nats layer.

[Mees-Molenaar]

I agree with @lxfontes here.

However, what if you have a workload consisting of components A and B. Component A changes a lot, so you have to redeploy your workload. But component B does not change a lot, which gives an overhead of redeploying component B as well.

Would it then be wise to separate the components into two workloads and let component A and B communicate through wasmcloud/messaging?