Bumps [github.com/xanzy/ssh-agent](https://github.com/xanzy/ssh-agent) from 0.2.1 to 0.3.1.
- [Release notes](https://github.com/xanzy/ssh-agent/releases)
- [Commits](https://github.com/xanzy/ssh-agent/compare/v0.2.1...v0.3.1

)

---
updated-dependencies:
- dependency-name: github.com/xanzy/ssh-agent
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

fix test fixture with multiple provider instances

When a test uses multiple instances of the same provider, we may need to
have separate objects to prevent overwriting of the MockProvider state.
Create a completely new MockProvider in each factory function call
rather than re-using the original provider value.

Running the tool this way ensures that we'll always run the version
selected by our go.mod file, rather than whatever happened to be available
in $GOPATH/bin on the system where we're running this.

This change caused some contexts to now be using a newer version of
staticcheck with additional checks, and so this commit also includes some
changes to quiet the new warnings without any change in overall behavior.

A snapshotDir tracks its current position as part of its state, so we need
to use it via pointer rather than value so that Readdirnames can actually
update that position, or else we'll just get stuck at position zero.

In practice this wasn't hurting anything because we only call Readdir once
on our snapshots, to read the whole directory at once. Still nice to fix
to avoid a gotcha for future maintenence, though.

Allow these to share the same backing MockProvider.

fix test fixture had the instance in the wrong mod

Make the state match the fixture config. The old test was not
technically invalid, but because it caused multiple instances of the
provider to be created, they were backed by the same MockProvider value
resulting in the `*Called` fields interfering.

Bumps [github.com/agext/levenshtein](https://github.com/agext/levenshtein) from 1.2.2 to 1.2.3.
- [Release notes](https://github.com/agext/levenshtein/releases)
- [Commits](https://github.com/agext/levenshtein/compare/v1.2.2...v1.2.3

)

---
updated-dependencies:
- dependency-name: github.com/agext/levenshtein
  dependency-type: direct:production
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

CVE-2020-26160 is a high-severity advisory reported against this module.

The dgrijalva package is no longer maintained but our legacy etcv2 backend
depends on it indirectly, via go.etcd.io/etcd/client. The golang-jwt
package is the blessed successor of the original, and has a v3 line which
is compatible with the v3 line of dgrijalva, and so through this replace
we can get a fix for the advisory without other significant behavior
change.

We've preserved the etcdv2 backend as-is on a best-effort basis in order
to support anyone who is already using it, but recommend that users switch
to etcdv3 or to some other backend for ongoing use.

We also have future plans to make state storage be a matter for provider
plugins rather than built in to Terraform CLI, at which point this backend
will either become obsolete or be factored out into its own plugin, at
which point we can remove this "replace" directive and the associated
dependency altogether.

Bumps [honnef.co/go/tools](https://github.com/dominikh/go-tools) from 0.0.1-2020.1.4 to 0.3.0-0.dev.
- [Release notes](https://github.com/dominikh/go-tools/releases)
- [Commits](https://github.com/dominikh/go-tools/compare/v0.0.1-2020.1.4...v0.3.0-0.dev

)

---
updated-dependencies:
- dependency-name: honnef.co/go/tools
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

This is just a routine upgrade to the latest v1 release.

Bumps [github.com/mitchellh/copystructure](https://github.com/mitchellh/copystructure) from 1.0.0 to 1.2.0.
- [Release notes](https://github.com/mitchellh/copystructure/releases)
- [Commits](https://github.com/mitchellh/copystructure/compare/v1.0.0...v1.2.0

)

---
updated-dependencies:
- dependency-name: github.com/mitchellh/copystructure
  dependency-type: direct:production
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [github.com/hashicorp/go-plugin](https://github.com/hashicorp/go-plugin) from 1.4.1 to 1.4.3.
- [Release notes](https://github.com/hashicorp/go-plugin/releases)
- [Commits](https://github.com/hashicorp/go-plugin/compare/v1.4.1...v1.4.3

)

---
updated-dependencies:
- dependency-name: github.com/hashicorp/go-plugin
  dependency-type: direct:production
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Check for nil change during apply

Bump google.golang.org/protobuf from 1.25.0 to 1.27.1

Because NodeAbstractResourceInstance.readDiff can return a nil change,
we must check for that in all callers.

don't refresh deposed instances during the destroy plan

Update go1.17.2

Since we have to specify the minor release for `.go-version`, make sure
the CI version doesn't automatically udpate.

add better error if credentials are invalid

Co-authored-by: appilon <apilon@hashicorp.com>

Resetting the *Called fields and enforcing configuration broke a few
tests.

The destroy plan should not require a configured provider (the complete
configuration is not evaluated, so they cannot be configured).

Deposed instances were being refreshed during the destroy plan, because
this instance type is only ever destroyed and shares the same
implementation between plan and walkPlanDestroy. Skip refreshing during
walkPlanDestroy.

Have the MockProvider ensure that Configure is always called before any
methods that may require a configured provider.

Ensure the MockProvider *Called fields are zeroed out when re-using the
provider instance.

json-output: Release format version 1.0

We have various mechanisms that aim to ensure that the installed provider
plugins are consistent with the lock file and that the lock file is
consistent with the provider requirements, and we do have existing unit
tests for them, but all of those cases mock our fake out at least part of
the process and in the past that's caused us to miss usability
regressions, where we still catch the error but do so at the wrong layer
and thus generate error message lacking useful additional context.

Here we'll add some new end-to-end tests to supplement the existing unit
tests, making sure things work as expected when we assemble the system
together as we would in a release. These tests cover a number of different
ways in which the plugin selections can grow inconsistent.

These new tests all run only when we're in a context where we're allowed
to access the network, because they exercise the real plugin installer
codepath. We could technically build this to use a local filesyste...

In the original incarnation of Meta.providerFactories we were returning
into a Meta.contextOpts whose signature didn't allow it to return an
error directly, and so we had compromised by making the provider factory
functions themselves return errors once called.

Subsequent work made Meta.contextOpts need to return an error anyway, but
at the time we neglected to update our handling of the providerFactories
result, having it still defer the error handling until we finally
instantiate a provider.

Although that did ultimately get the expected result anyway, the error
ended up being reported from deep in the guts of a Terraform Core graph
walk, in whichever concurrently-visited graph node happened to try to
instantiate the plugin first. This meant that the exact phrasing of the
error message would vary between runs and the reporting codepath didn't
have enough context to given an actionable suggestion on how to proceed.

In this commit we make Meta.contextOpts pass through directly any error
that Meta.providerFactories produces, and then make Meta.providerFactories
produce a special error type so that Meta.Backend can ultimately return
a user-friendly diagnostic message containing a specific suggestion to
run "terraform init", along with a short explanation of what a provider
plugin is.

The reliance here on an implied contract between two functions that are
not directly connected in the callstack is non-ideal, and so hopefully
we'll revisit this further in future work on the overall architecture of
the CLI layer. To try to make this robust in the meantime though, I wrote
it to use the errors.As function to potentially unwrap a wrapped version
of our special error type, in case one of the intervening layers is
changed at some point to wrap the downstream error before returning it.

objchange: fix ProposedNew from null objects