Fixes #30881

fix(creds): allow periods in TF_TOKEN_... credentials vars

test(cloud): ensure mocks are used for backend configure tests

* internal/getproviders: Add URL to error message for clarity

Occasionally `terraform init` on some providers may return the following error message:

Error while installing citrix/citrixadc v1.13.0: could not query provider
registry for registry.terraform.io/citrix/citrixadc: failed to retrieve
authentication checksums for provider: 403 Forbidden

The 403 is most often returned from GitHub (rather than Registry API)
and this change makes it more obvious.

* Use Host instead of full URL

docs: Fix typo in v1.0 upgrade guide

remove the use of data source prior state from planning

data schema changes may prevent state decoding

Cloud e2e tests for configuring `cloud` with env vars

Allow remote service creds to be configured using env

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

Hyphen characters are allowed in environment variable names, but are not valid POSIX variable names. Usually, it's still possible to set variable names with hyphens using utilities like env or docker. But, as a fallback, host names may encode their hyphens as double underscores in the variable name. For the example "café.fr", the variable name "TF_TOKEN_xn____caf__dma_fr" or "TF_TOKEN_xn--caf-dma_fr"
may be used.

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

Introduces a new method of configuring token service credentials using a host-specific environment variable. This configuration was previously possible using the [terraform-credentials-env](https://github.com/apparentlymart/terraform-credentials-env) credentials helper.

This new method is now consulted first, as it is seen to be the most proximate source of credentials before CLI configuration while still falling back to the credentials helper.

cli: Fix double-quoted map keys in diff UI

Also adds a few new tests for cloud configuration using environment variables

A previous change added missing quoting around object keys which do not
parse as barewords. At the same time we introduced a bug where map keys
could be double-quoted, due to calling the `displayAttributeName` helper
function (to quote non-bareword keys) then using the `writeValue` method
(which quotes all strings).

This commit fixes this and adds test coverage for map keys which require
quoting.

- follows: https://github.com/hashicorp/terraform-cdk/pull/1611

Add cloud config support for TF_WORKSPACE

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

Data sources should not require reading the previous versions. While we
previously skipped the decoding if it were to fail, this removes the
need for any prior state at all.

The only place where the prior state was functionally used was in the
destroy path. Because a data source destroy is only for cleanup purposes
to clean out the state using the same code paths as a managed resource,
we can substitute the prior state in the change change with a null value
to maintain the same behavior.

After data source handling was moved from a separate refresh phase into
the planning phase, reading the existing state was only used for
informational purposes. This had been reduced to reporting warnings when
the provider returned an unexpected value to try and help locate legacy
provider bugs, but any actual issues located from those warnings were
very few and far between.

Because the prior state cannot be reliably decoded when faced with
incompatible provider schema upgrades, and there is no longer any
significant reason to try and get the prior state at all, we can skip
the process entirely.

Data sources do not have state migrations, so there may be no way to
decode the prior state when faced with incompatible type changes.

Because prior state is only informational to the plan, and its existence
should not effect the planning process, we can skip decoding when faced
with errors.

cli: Fix plan diff for sensitive nested attributes

When rendering diffs for resources which use nested attribute types, we
must cope with collections backing those attributes which are entirely
sensitive. The most common way this will be seen is through sensitive
values being present in sets, which will result in the entire set being
marked sensitive.