* Update go-cty to latest version

* go mod tidy

go get -u golang.org/x/net

Add Documentation Issue form template

Co-authored-by: Judith Malnick <judith.patudith@gmail.com>

This reverts commit 84edd844.

This reverts commit 0a7e221a.

[COMPLIANCE] Update MPL 2.0 LICENSE

The graph walking mechanism is specified as requiring a graph with a single
root, which in practice means there's exactly one node in the graph
which doesn't have any dependencies.

However, we previously weren't verifying that invariant is true for
subgraphs returned from DynamicExpand. It was working anyway, but it's not
ideal to be relying on a behavior that isn't guaranteed by our underlying
infrastructure.

We also previously had the RootTransformer being a bit clever and trying
to avoid adding a new node if there is already only a single graph with
no dependencies. That special case isn't particularly valuable since
there's no harm in turning a one-node graph into a two-node graph with
an explicit separate root node, and doing that allows us to assume that
the root node is always present and is always exactly terraform.rootNode.

Many existing DynamicExpand implementations were not producing valid
graphs and were previously getting away with it. All of them now produce
properly-rooted graphs that should pass validation, and we will guarantee
that with an explicit check of the DynamicExpand return value before we
try to walk that subgraph. For good measure we also verify that the root
node is exactly terraform.rootNode, even though that isn't strictly
required by our graph walker, just to help us catch potential future bugs
where a DynamicExpand implementation neglects to add our singleton root
node.

docs/plugin-protocol: Add notes about missing configuration in ReadResource and UpgradeResourceState request messages (#31998)

This opts to inline document these intentional design decisions in the protocol definition as a catch-all for it not being documented elsewhere.

Protocol Buffers files updated via:

```shell
make protobuf
```

core: A NoOp orphan change has nothing to apply

An orphaned resource which plans as a NoOp change will have no config.
This is not an error, but there is nothing to do since there are also
no checks to validate. We still leave the change in the plan to keep the
plan as complete as possible, noting all possible changes.

Preventing the node from being added to the graph is awkward, because
the config is attached separately from the diff transformer. This should
not pose any problems however, because there is no longer any state or
config linking the instance to any dependencies in the graph.

* Add support for `storage_custom_endpoint` in `gcs` backend

* Add documentation for new `storage_custom_endpoint` endpoint

* Empty commit to trigger Vercel deployment

Add support for pre-apply task results in the cloud backend

Clarify some comments in internal/dag

When reading this code to check Terraform's graph sorting behavior, I got very
confused about the direction of traversal for several methods. Although some of
these methods would also probably benefit from renames, this commit only updates
their doc comments to use the same directional terminology that we use in the
`Edge` interface (source/target).

Thanks!
Co-authored-by: Judith Malnick <judith.patudith@gmail.com>

Thanks!
Co-authored-by: Judith Malnick <judith.patudith@gmail.com>

Adding mention of no-code to Creating Modules section of TF Language docs

Add callout to Continuous Validation

Closes https://github.com/hashicorp/terraform/issues/31552. 

Adds a new issue form type for documentation issues. Format discussed with docs team.

Update backends.mdx

evaluation of missing instances during import

Because import does not yet plan new instances as part of the import
process, we can end up evaluating references to resources which have no
state at all. The fallback for this situation could result in slightly
better values during import. The count and for_each values were
technically incorrect, since the length is not known to be zero, and the
single instance does have a concrete type which we can return.

Extract more exact provider name when checking for destroy cycles

When we checked for cycles with destroy edges around providers, it was
only for providers of a different type, but one can do the same thing
with the same provider under different local aliases. Check to see if
the provider also contains an alias, or is defined absolutely in some
other way. The absolute accuracy here isn't critical, since in most
cases these edges are not required for correct results, but finding a
correct and consistent method for determining when these edges are
needed is going to take more research.

There was also an oversight fixed here where the basic
creator->destroyer edges were added _after_ the cycle checks, limiting
their utility. The ordering of the additions was swapped to make sure
all cycles are noticed.

special handling for legacy `ignore_changes = all`