"HCL2"-based validate command

[apparentlymart]

Note: The target of this PR is the v0.12-dev branch, because this change is not shippable in isolation.

This is the first of many more changes required to fully integrate the "HCL2" implementation of HCL into Terraform. As a mostly-isolated starting point this changes the terraform validate command to use the new parser.

As proposed in #15895, this reduces slightly the scope of the terraform validate command to just "safe" static validation, which will eventually include checking configuration values against provider validation rules but will not do any "dynamic" validation that requires per-run context, state, etc.

This changeset anticipates (but does not yet implement) a terraform plan -validate-only mode that does a slightly-deeper validation with the full context of a particular run, including a set of variables, the current state, etc. The distinction between these two commands is:

• terraform validate asks "is this configuration valid, regardless of what context it's applied in?", and is a good check for a text editor integration to run automatically on save, since it requires no credentials or other contextual information.
• terraform plan -validate-only asks "is this proposed change valid?", and does all the same checks as terraform validate but also ensures that we have appropriate values for all variables. This might be a good command to run in order to smoke-test a pull request to the configuration of a real environment, for example.

Currently the distinction feels unclear because all operation context is local anyway, but it will become more significant in future when we implement backend-stored per-workspace variables and a backend that is able to run terraform plan remotely, both of which will require network requests to the backend in order to do full validation of a proposed change, as opposed to validation of just the configuration. terraform validate promises to always be local-only.

---

This set of changes was originally written in order to allow a first pass of batch-validating a set of "real-world" Terraform modules to pick some low-hanging parser bugs. (And it did! In hashicorp/hcl2#15, hashicorp/hcl2#16, hashicorp/hcl2#17, hashicorp/hcl2#18, hashicorp/hcl2#19, and hashicorp/hcl2#21.)

As a consequence of that goal, this patch also includes some extra functionality beyond just a port of the existing terraform validate command:

• Some support code is added to command to allow us to convenient load configurations via a centralized loader. which then allows us to populate the source code cache we'll use for source code snippets in diagnostics.

• The diagnostics printer is now able to print out source code snippets for errors that are able to generate them:

• The validate command has a JSON output mode. In future we will probably extend other commands with similar output, when Terraform's workflow is more stable and we're more confident that we won't need to break the format, but at least for this command the result format is unlikely to significantly change, because it's just a list of errors and warnings. This output format is hopefully useful for integrating "validate on save" functionality in text editor extensions.

{
  "valid": false,
  "error_count": 1,
  "warning_count": 0,
  "diagnostics": [
    {
      "severity": "error",
      "summary": "Unsupported block type",
      "detail": "Blocks of type \"vaariable\" are not expected here. Did you mean \"variable\"?",
      "range": {
        "filename": "variables.tf",
        "start": {
          "line": 1,
          "column": 1,
          "byte": 0
        },
        "end": {
          "line": 1,
          "column": 10,
          "byte": 9
        }
      }
    }
  ]
}

• The temporary validation test harness also included some incomplete terraform init updates in order to install modules to validate, which are not included here. However this changeset does include a configload.InstallHooks implementation that can print installation progress to the UI. That's included here mainly just to keep it safe for later, when we make the more-complete terraform init updates.

This changeset temporarily breaks the "deep" validation done by walking the graph, instead just doing syntax validation. The validation of resource configurations against schema, etc, will be added back later once Terraform Core has been updated to work with the new configuration structures.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.