This symbol produces an ephemeral boolean value that's true when the
stack evaluator is configured for applying and false otherwise.
The primary purpose of this is to allow specifying a more privileged auth
role in a provider configuration during the apply phase, while allowing
the plan phase to use a read-only or otherwise-less-privileged role.
This allows us to talk about references between expressions in absolute
terms, taking into account the stack where a particular expression would
be resolved.
This isn't an appropriate representation for references like each.key,
since those require a more specific scope than just a stack, but that's
okay because those contextual reference types can't depend on anything
other than what they are embedded inside anyway, and so we never need to
consider them when we're doing global reference analysis.
Because many stacks language features are dependent on others to do useful
work, it's tempting to focus only on integration testing of combinations
of features used together. However, we known from our experience with the
modules runtime (the "terraform" package) that over time this becomes a
huge maintenance burden, because any non-trivial change tends to
invalidate hundreds or thousands of integration tests, and because of their
broad scope its often hard in retrospect to figure out what exactly a
particular test was aiming to test vs. what it was just relying on as a
side-effect.
To try to minimize these cross-dependencies and thus enable something
closer to unit testing, here we introduce a special kind of symbol to the
stacks language which is available only to unit tests in this package.
"Test-only globals" -- an intentionally-clunky name to avoid squatting on
useful names -- can be set as part of the Main object and, when defined,
are available for use in all situations where we perform expression
evaluation against a stack. The "globals" in the name represents that,
unlike just about everything else, they are defined once but available in
all stacks in the configuration tree.
This design is a tradeoff: it introduces a bunch of extra code that is
here entirely to support testing, but hopefully this code is segregated
enough from everything else that it's unlikely to change significantly
under future maintenance, thereby hopefully minimizing the need for future
cross-cutting test maintenance too.
