Add a rule to catch when typed object arguments to modules provide extra keys

[DanDanN00dle]

Introduction

In terraform, the parser will quietly coerce arguments to a module that uses object-typed parameters to the target type by discarding extra keys. The rationale being that this reduces friction & dependency-hell between modules when one module takes an input generated as an output from another module. However, when the argument is generated in the root terraform or provided as a literal, discarding a key generally signals a miscommunication or incompatibility with a new module version. Worse, it may just be a misspelling of the object key.

Proposal

Given a terraform configuration with a module that defines a variable of type 'object'
When the terraform provides a map/object literal and that literal contains a key that is not specified in the declared module type structure,
Then tflint will flag this as an error.

Ideally this will also flag:

1. When the map/object discrepancy is in a nested object declaration.
2. When the map/object is a local variable reference.
3. When the map/object is constructed through the merge of multiple objects.
4. When the map/object is an output variable from another module where the structure can be determined.

An example of this is:

amodule/variables.tf:

variable "a" {
  type = object({
    key1 = string
  })

main.tf: (root terraform configuration)

module "amodule" {
  src = "./amodule"
  a = {
    key1 = "hello"
    key2 = "world"
  }
}

Currently, terraform silently ignores a.key2, we are proposing that tflint will highlight this error.

References

Corresponding terraform issue
Documentation on lossy map -> object conversions

[wata727]

This seems like something worth considering, but it's debatable in which cases it should be flagged or not.
If you're passing literals directly into the module arguments, I believe it's more likely a typo or oversight, but if you're making use of variables or merging objects, it may be that you're intentionally expecting the extra keys to be ignored.

Another challenge is that the current SDK does not have an API to get the variable definitions of a module, so we have to tackle that first. Moreover, remote modules are not always accessible, so there is a possibility that some module calls may not be detected correctly.

[DanDanN00dle]

Agree on all points and that's one reason I phrased my suggestion "success criteria" the way I did...

The most obvious use case is a literal map being passed -- this is almost always going to be user error or an unexpected module behavior change. Having this would be a big help towards ferreting out defects because otherwise you pretty much have to go manually verify the plan or the resulting infrastructure.

When you start adding variables, it does get a little more dicey -- sometimes stepping pretty far out of the realm of static analysis (for example, variable structures that depend on the values in vars unknown until plan time).