Although we have a fair number of hand-written unit tests for different
permutations of expression evaluation, when writing those we tend to
favor relatively straightforward situations which only include a single
operator or function at a time, and thus we can sometimes miss including
test cases for less common situations that can arise when combining
different features together.

This new package and its associated CLI tool are intended to randomly
generate various valid expressions with different combinations of
expression operators and functions from the Terraform language, and then
check to make sure that they evaluate successfully and produce a result
of the expected type, mode, and sensitivity. Hopefully this will allow us
to find problems that we wouldn't think to test.

This is a similar sort of idea as fuzz testing, but at a higher level of
abstraction where the input is intended to always be a valid expression
and we're focused on the evaluator, rather than generating random bytes
and trying to crash the HCL parser. This is a form of property-based
testing, albeit applying the same set of properties to all possible
expressions rather than testing unique properties of each expression type.

validate provider_meta contains no interpolations

The provider_meta specification does not allow interpolation, but we
were not preventing it in the configuration.

This PR extends jsonprovider to support attributes with NestedTypes and extends test coverage in jsonprovider and the providers schemas tests. I've also cleaned up some comments and extracted the logic to parse the nesting mode so it can be used in both marshalling blocks and attributes.

docs: Update link to HCL native syntax spec

* Add helper suggestion when failed registry err

When someone has a failed registry error on init, remind them that
they should have required_providers in every module

* Give suggestion for a provider based on reqs

Suggest another provider on a registry error, from the list of
requirements we have on init. This skips the legacy lookup
process if there is a similar provider existing in requirements.

do not panic if there is no deposed state

NodeDestroyDeposedResourceInstanceObject should not panic if the deposed
state no longer exists.

destroying data source does not require a provider

Fixes #27506

Add a new flag `-lockfile=readonly` to `terraform init`.
It would be useful to allow us to suppress dependency lockfile changes
explicitly.

The type of the `-lockfile` flag is string rather than bool, leaving
room for future extensions to other behavior variants.

The readonly mode suppresses lockfile changes, but should verify
checksums against the information already recorded. It should conflict
with the `-upgrade` flag.

Note: In the original use-case described in #27506, I would like to
suppress adding zh hashes, but a test code here suppresses adding h1
hashes because it's easy for testing.
Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>

The provider transformers remove extra provider nodes when they are
initially setup, but it may turn out that they are not used later on.

The pruneUnusedNodesTransformer takes care of removing unused expansion
nodes, which originally required a provider, and hence may cause some
provider nodes to no longer be needed. We can also detect these and
remove them during the pruneUnusedNodesTransformer process.

Removing a data source is a state-only operation, and the node itself
does not require a provider.

Clarify the use of this transformer, interface and method which now does
not apply to anything but `depends_on` for data sources,

functions: Fix panics in defaults

core: Reduce string allocations for addrs Equal

Generating strings and comparing them to implement Equal is a quick and
easy solution. Unfortunately when this code is in the hot path, it
becomes very expensive, so this commit changes some of those instances
to compare the values directly.

Combined with using addr.Equal instead of checking for string equality,
this makes Terraform dramatically faster for some operations, such as
generating large JSON plans.

views: Fix missing source in diagnostic output

We allow primitive fallback values which have mismatched types, but only
if there is a conversion to the target type. Previously we would allow
unsafe conversions (e.g. string to bool), but later had no capacity to
return an error if the conversion failed due to the value of the
fallback being unable to convert to the target type.

This commit makes the more conservative requirement that default
fallback values must have a safe conversion.

When applying default values to collection types, null collections in
the input should result in empty collections in the output.

* Fix auto-approve for soft-policy
* Update error handling
* update testing string for consistency

The previous implementation of views was copying and embedding the base
View struct in each individual view. While this allowed for easy access
to the interface of that struct (both in the view and externally), it more
importantly completely broke the ability of the diagnostic printer to
output source code snippets.

This is because the `configSources` field on the base view is lazily set
after the config loader is initialized. In the commands ported to use
views, this happens after the base View struct is copied, so we are
updating the wrong copy of the struct.

This commit fixes this with a simple mechanical refactor: keep a pointer
to the base View struct instead, and update all of the individual views
to explicitly refer to that struct to access its fields and methods.

This is not a particularly satisfying solution, but I can't find
anything clearly better. It might be worth exploring the alternative
approach in the view for the new test command, which explicitly pulls
its dependencies out of the base view, rather than retaining a full
reference. Maybe there's a third way which is better still.

We expect that in order to continue to evolve the language without
breaking existing modules we will at some point need to have a way to mark
when a particular module is expecting a newer interpretation of the
language.

Although it's too early to do any deep preparation for that, this commit
aims to proactively reserve an argument named "language" inside
"terraform" blocks, which currently only accepts the keyword TF2021 that
is intended to represent "the edition of the Terraform language as defined
in 2021".

That argument also defaults to TF2021 if not set, so in practice there's
no real reason to set this today, but this minimal validation today is
intended to give better feedback to users of older Terraform versions in
the event that we introduce a new language edition later and they try to
use an module incompatible with their Terraform version.

Our previous message conflated the requirement for a full sentence with
the suggestion to write in a style similar to Terraform's built-in error
messages, which created a sense that the system would actively reject an
error message written in another language.

There's no intent here to block writing error messages in other languages,
but there is a practical consideration that Terraform's UI output is
currently not localized and so consistency with Terraform's other output,
if that's important to a module author, will typically mean writing the
error message in English.

This isn't incredibly important, but Kitchen-Terraform is written in and requires tests to be written in Ruby.

Some command views cleanup

check errors before using configSnap

configSnap may be nil if there are errors loading it from the plan file.

* update arch docs; remove old EvalNode and EvalTree references

Revert "match terraform-releases expectations"

This reverts commit 270de49e.

match terraform-releases expectations

remote provisioners require a connection config