Debugged state locking issue with customer - customer presumed consul agent wasn't required as this page doesn't mention that fact. Without the agent Consul backend can be used but state locking is not possible.

lang: Add file_exists function

This contains a fix for a panic in Value.HasElement when used on a set
value whose element type is an object or tuple.

A few other minor dependency upgrades came long for the ride.

ProposedNewObject intentionally replaces a null prior with an unknown
prior in order to easily fill in unknown values where they "show through"
under values not set explicitly in config, but it was failing to handle
that situation when dealing with nested blocks that are backed by sets.

Due to the unusual way v0.12 was developed (because of the large amount
of cross-cutting refactoring) we have not built out an incremental
changelog along the way as we normally would.

This is an initial catchup of the changelog for the current tree at the
time of writing, with the intent that we will maintain this in the usual
way moving forward as we head towards the v0.12-alpha1 release.

helper/validation: Add All() and IntInSlice() SchemaValidateFunc

`All()` combines the outputs of multiple `SchemaValidateFunc`, to reduce the usage of custom validation functions that implement standard validation functions.

Example provider usage:

```go
ValidateFunc: validation.All(
  StringLenBetween(5, 42),
  StringMatch(regexp.MustCompile(`[a-zA-Z0-9]+`), "value must be alphanumeric"),
),
```

`IntInSlice()` is the `int` equivalent of `StringInSlice()`

Example provider usage:

```go
ValidateFunc: validation.IntInSlice([]int{30, 60, 120})
```

Output from unit testing:

```
$ make test TEST=./helper/validation
==> Checking that code complies with gofmt requirements...
go generate ./...
2018/10/17 14:16:03 Generated command/internal_plugin_list.go
go list ./helper/validation | xargs -t -n4 go test  -timeout=2m -parallel=4
go test -timeout=2m -parallel=4 github.com/hashicorp/terraform/helper/validation
ok  	github.com/hashicorp/terraform/helper/validation	1.106s
```

helper/resource tests

Backend config and command tests

The helper/resource unit tests will panic, because they were using the
legacy terraform.MockResourceProvider, which doesn't have the same
internals required by the new GRPC shims.

Fail these tests for now, and a new test provider will need to be made
out of a schema.Provider instance.

This makes sure we don't create a backup of an intermediate state if the
first read state was empty.

The cli should override the config

The master branch is now tracking towards the v0.12 release.

This work was done against APIs that were already changed in the branch
before work began, and so it doesn't apply to the v0.12 development work.

To allow v0.12 to merge down to master, we'll revert this work out for now
and then re-introduce equivalent functionality in later commits that works
against the new APIs.

After a bunch of recent changes/rebasing our vendored dependencies got a
little out of sync w.r.t transitive dependencies through codebases that
are not themselves Go Modules yet.

Even if a provider doesn't indicate a specific attribute as the cause of
a resource operation error, we know the error relates to some aspect of
the resource, so we'll include that approximate information in the result
so that we don't produce user-hostile error messages with no context
whatsoever.

Later we can hopefully refine this to place the source range on the header
of the configuration block rather than on an empty part of the body, but
that'll require some more complex rework here and so for now we'll just
accept this as an interim state so that the user can at least figure out
which resource block the error is coming from.

This ensures more HCL1/HIL-like behaviors when dealing with nested blocks
that are not set in the configuration, which is important for
compatibility with helper/schema's validation logic.

This is a more specialized version of ConfigValueFromHCL2 which is
specifically for config values that represent the content of a block
body in the configuration.

By using the schema of that block we can more precisely emulate the old
HCL1/HIL behaviors by distinguishing attributes from blocks and applying
some slightly different behaviors for the handling of null values and
of empty collections that are representing the absense of blocks of a
particular type.

The last 2 broken tests will be hanlded later

Use the new SimpleDiff method of the provider so that the diff isn't
altered by ForceNew attributes.

Always set an "id" as RequiresReplace so core knows an instance will be
replaced, even if all ForceNew attributes are filtered out due to
ignore_changes.

The underlying bug that was causing this test to hang has since been
fixed.

If we don't override these then the tests can only pass on one platform.

This reinstates an old behavior that was lost in the reorganization of how
we deal with the -var and -var-file options.

This fix is verified by TestApply_planVars now passing.

In the new implementation of collecting variables I initially forgot the
JSON variant of terraform.tfvars.

This fix is verified by TestApply_varFileDefaultJSON now passing.

Terraform now handles any actual "diffing" of resource, and the existing
Diff functions are only used to shim the schema.Provider to the new
methods. Since terraform is handling what used to be the Diff, the
provider now should not modify the diff based on RequiresNew due to it
interfering with the ignore_changes handling.

The helper resource tests won't pass for now, as they use a
terraform.MockProvider which can't be used in the schema.Provider shims.

We need to ensure that a destroyed value is returned as such from apply

Tests often call Plan multiple times on the same context to verify there
are no changes, so we need to make sure changes don't accumulate.

We also need to convert legacy states for helper resource tests.