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>

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>

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>

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>

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

When a data resource is used for the purposes of verifying a condition
about an object managed elsewhere (e.g. if the managed resource doesn't
directly export all of the information required for the condition) it's
important that we defer the data resource read to the apply step if the
corresponding managed resource has any changes pending.

Typically we'd expect that to come "for free" but unfortunately we have
a pragmatic special case in our handling of data resources where we
normally defer to the apply step only if a _direct_ dependency of the data
resource has a change pending, and allow a plan-time read if there's
a pending change in an indirect dependency. This allowed us to preserve
some compatibility with the questionable historical behavior of always
reading data resources proactively unless the configuration contains
unknown values, since the arguably-more-correct behavior would've been a
regression for anyone who had been depending on that before.

Since preconditions and postconditions didn't exist until now, we are not
constrained in the same way by backward compatibility, and so we can adopt
the more correct behavior in the case where a data resource has conditions
specified. This does unfortunately make the handling of data resources
with conditions subtly inconsistent with those that don't, but this is
a better situation than the alternative where it would be easy to get into
a trapped situation where the remote system is invalid and it's impossible
to plan the change that would make it valid again because the conditions
evaluate too soon, prior to the fix being applied.

We have two different reasons why a data resource might be read only
during apply, rather than during planning as usual: the configuration
contains unknown values, or the data resource as a whole depends on a
managed resource which itself has a change pending.

However, we didn't previously distinguish these two in a way that allowed
the UI to describe the difference, and so we confusingly reported both
as "config refers to values not yet known", which in turn led to a number
of reasonable questions about why Terraform was claiming that but then
immediately below showing the configuration entirely known.

Now we'll use our existing "ActionReason" mechanism to tell the UI layer
which of the two reasons applies to a particular data resource instance.
The "dependency pending" situation tends to happen in conjunction with
"config unknown", so we'll prefer to refer that the configuration is
unknown if both are true.

Also add this path to .gitignore to prevent future mistakes.

* feat: pull over content for `/docs`

* chore: format json

Backport of plugin: diagnostics must be checked on all schema calls into v1.2

* backport of commit 1ee5d23894a0c9448d6787e0385dbba356db8096

* backport of commit 565e6ba2b378556a6d03e9ee021553670e1fc6c8
Co-authored-by: Anna Winkler <3526523+annawinkler@users.noreply.github.com>

Merge pull request #30986 from hashicorp/backport/alisdair/fix-ssh-http-proxy-panic/poorly-saved-kangaroo

Backport of communicator/ssh: Fix crash using SSH+HTTP proxy into v1.2

Backport of check for cancellation before apply confirmation into v1.2

Backport of Add note about lockfile's relationship to state  into v1.2