Add GitHub Action for autolabeling and assigning reviewers for Dependabot PRs based on the dependency updated

Command state mv: Error when backup or backup-out options are used without the state option on non-local backends

Error if backup or backup-out options are used without the state option on non-local backends for the state mv command

* convert uses of worspaces.operations into workspaces.executionMode

The cloud package currently uses a deprecated API on workspaces to determine a workspace's execution mode.

Deprecated: Operations (boolean)
New hotness: Execution mode (string - "local", "remote", or "agent")

More details: https://www.terraform.io/docs/cloud/api/workspaces.html#request-body



All uses of Operations field coming from the client (within the cloud package) should be converted to the appropriate ExecutionMode equivalent.
Also, we need to update all acknowledgment of operations field on the tests that are testing the behavior of workspaces.
Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>
Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>

We have a few dependencies that are such a significant part of Terraform's
behavior that they will often be the root cause of or the solution to a
bug reported against Terraform.

As a small quality-of-life improvement to help with diagnosing those,
we'll now report the selected versions for each of these so-called
"interesting" dependencies as part of our initial trace log output during
Terraform startup.

The goal here is that when someone opens a bug report, and includes the
trace log as our bug report template requests, we'll be able to see at a
glance which versions of these dependencies were involved, instead of
having to manually cross-reference in the go.mod file of the reported main
Terraform CLI version.

This does slightly grow the general overhead of the logs, but as long as
we keep this set of interesting dependencies relatively small it shouldn't
present any significant problem in typical usage.

Fix typo in 0.13 upgrade guide

cloud: Add streamlined 'remote' backend state migration path

For Terraform Cloud users using the 'remote' backend, the existing
'pattern' prompt should work just fine - but because their workspaces
are already present in TFC, the 'migration' here is really just
realigning their local workspaces with Terraform Cloud. Instead of
forcing users to do the mental gymnastics of what it means to migrate
from 'prefix' - and because their remote workspaces probably already exist and
already conform to Terraform Cloud's naming concerns - streamline the
process for them and calculate the necessary pattern to migrate as-is,
without any user intervention necessary.

cloud: Autoselect migrated current workspace + migrate UX adjustments

After migrating to TFC with renamed workspaces, automatically select
what was the previous current workspace on behalf of the user. We don't
need to make the user reselect.

Note these change do break the internal/cloud/e2e tests; they are in a
sad state that needs adjusting anyway, so I'm not updating them for
these changes at this time.

backend/oss: Removes the ConflictWith tag which on the attributes assume_role* to fix the incompatible error

generate precise resource types during validate

update go-cty to v1.10.0

backend/oss: Removes the ConflictWith tag which on the attributes assume_role* to fix the incompatible error

Cloud: Update Workspace during Tags strategy

cty: The documented definition and comparison logic of cty.Number is now
refined to acknowledge that its true range is limited only to values
that have both a binary floating point and decimal representation,
because cty values are primarily designed to traverse JSON serialization
where numbers are always defined as decimal strings.

In particular, that means that two cty.Number values now always compare
as equal if their representation in JSON (under cty's own JSON encoder)
would be equal, even though the decimal approximation we use for that
conversion is slightly lossy. This pragmatic compromise avoids confusing
situations where a round-trip through JSON serialization (or other
serializations that use the same number format) may produce a value that
doesn't compare equal to the original.

This new definition of equals should not cause any significant behavior
change for any integer in our in-memory storage range, but may cause
some fractional values to compare equal where they didn't before if they
differ only by a small fraction.

command: Update backend hash value only after a successful migration

The Meta.backend_C_r_S_unchanged() method was sadly a bit of a mess.

It seems to have originally been used as a method to be called
when the backend is not changing, with an extra assumption that if the
configured backend's hash doesn't match the one in state, surely the
hash should just be updated as an option might have been moved to
command line flags.

However, this function was used throughout this file as 'the method to
load the initialized (but not necessarily configured) backend',
regardless of whether or not it is the same (unchanged). This is in
addition to Meta.backendFromState(), which is used to load the same
thing except in the main codepath of 'init -backend=false'.

These changes separate the concerns of backend_C_r_S_unchanged() by

1) Fetching the saved backend (savedBackend())
2) Updating the hash value in the backend cache when appropriate (either
   by leaving it to the caller to do themselves or by calling
   updateSavedupdateSavedBackendHash())

This allows migration codepaths to *not* update the hash value until
after a migration has successfully taken place.

We only lookup providers by provider type to get the schema, so there's
no reason to generate anything more specific.

Allow `GetResource` to return correct types values during validation,
rather than relying on `cty.DynamicVal` as a placeholder. This allows
other dependent expressions to be more correctly evaluated.

Pulled and updated from
https://github.com/hashicorp/terraform/pull/26260

* command/format: fix list nested attr diff rendering

Previously, diffs only rendered correctly if all changed elements
appeared before all unchanged elements. Once an unchanged element was
found, all remaining elements were skipped. This usually led to the
output being an empty list with a weird amount of space between the
brackets.

* command/format: improve list nested attr rendering

This makes several changes that make diffs for lists clearer and more
consistent:

  * Separate items with brackets instead of only new lines. This better
    matches the input syntax and avoids confusion from the first and
    last brackets implying there is a single item.
  * Render an action symbol for each element of the list
  * Use the correct action symbol for new and deleted items
  * Fix the alignment of opening and closing brackets

I also refactored the structure so it is similar to the set and map
cases to minimize duplication of the new prints.

* Fix re-use of blockBodyDiffResult struct

configs: fix ignore_changes config override bug

cloud: Allow cloud tests to be run in parallel

backend/oss: Supports the new attribute sts_endpoint

nullable variable docs

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>