* stacks: add deferred resource instance planned change to protobuf
* stacks: add deferred resource instance to stack plan sequence
* stacks: add planned change for deferred actions
* stacks: refactor planned change resource instance planned
moving the components out of the main function definition so that we can reuse the implementation for deferred resource instances which wraps the message used for PlannedChangeResourceInstancePlanned
* stacks: track deferred changes in stackplan
* add simple tests
* fix tests
* address comments
---------
Co-authored-by: Liam Cervante <liam.cervante@hashicorp.com>
We allow experiments only in alpha builds, and so we propagate the flag
for whether that's allowed in from "package main". We previously had that
plumbed in only as far as the rpcapi startup.
This plumbs the flag all the way into package stackeval so that we can
in turn propagate it to Terraform's module config loader, which is
ultimately the one responsible for ensuring that language experiments can
be enabled only when the flag is set.
Therefore it will now be possible to opt in to language experiments in
modules that are used in stack components.
Previously we were accepting it at the API layer but then silently
discarding it and always creating a "normal" plan. Now we'll pass the
caller's selected planning mode all the way through to the modules runtime
in component plans.
This isn't actually quite sufficient to properly support destroy-mode plans
since the stacks runtime itself doesn't yet really understand how to
deal with things being destroyed, but this is intended to be just enough
for those working on callers of this API to see _some_ effect from setting
the planning mode, even though it's far from the full effect expected.
More work on destroying will follow in subsequent commits.
We previously took a few shortcuts just to more quickly produce a proof
of concept. This gets us considerably closer to a properly-working handoff
from plan to apply, at least for create, update, and replace actions.
Destroying stuff that's been removed from the configuration will take some
further work since currently everything we do is driven by objects in the
configuration. That will follow in later commits.
Now that we have access to a previous state snapshot during the planning
phase, we can pass the relevant parts to the modules runtime when asking
it to plan changes for a component instance.
This is not yet complete enough for full support of consecutive plan and
apply runs that preserve state, but it gets the needed data plumbed in
and we'll continue making this more complete in subsequent commits.
The closure of these channels is how a caller knows that the operation has
completed, so we must always close them before we return or the caller
is likely to get wedged.
Each declared provider configuration is now started up and configured
during planning. We don't actually do anything with them yet other than
shut them down again once the plan is complete, but we'll improve on that
in subsequent commits.
This nudges the placeholder "this is not a real plan" warning down one
more level in the stack, with stackruntime.Plan now being equipped to
propagate the individual planned changes and diagnostics up to the rpcapi
caller, which will in turn propagate them to its client.
This establishes the overall API shape but implementation-wise just moves
the warning that the implementation is fake one level deeper, with
stackruntime now being the one to return that warning instead of the
rpcapi package directly.
Package rpcapi now monitors the two output channels from stackruntime.Plan
and translates what it sees into protobuf events to transmit to the
client. Of course given the above that's currently always just exactly
one diagnostic and no planned changes, but we'll start to make the
stackruntime.Plan function real in subsequent commits.
