Add terraform query subcommand (TF-25494)

[dbanck]

This PR introduces a new (experimental) query command. The command reuses as much as possible from the existing plan operation implementation.

• There are two new UI hooks PreListQuery and PostListQuery. The latter is used to output the results of an individual list block
• We now store the list results in a separate QueryInstance in the plan changes, instead of using the ResourceInstanceChange. Even though we don't use this field for the CLI output

UX

Local Backend Human

Local Backend JSON

Cloud Backend

Target Release

1.14.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[liamcervante]

just some very early thoughts that jumped out to me - don't need to be addressed properly yet or anything.

[liamcervante]

Suggested change

	Results cty.Value
	Results []cty.Value

Since this must be a slice / tuple - is it perhaps more clear to just not include that part in the cty encoding? This makes it totally unambiguous that this is a list of things.

[dbanck]

Currently we're storing the result in the following form:

cty.ObjectVal(map[string]cty.Value{"data": cty.TupleVal(results), "config": config})

This matches the schema and makes encoding/decoding easy, but I guess we really only need the tuple val in the plan 🤔

[liamcervante]

metanote: because of the way things might change over time this may eventually become a list of structs in which one of the things that it might contain is the value. We might add some metadata about the query results (like you see in the ResourceInstanceChange for example.

This representation can change as it likes (as it is internal only) but eventually this will go into the jsonplan package which has to be more backwards compatible. At that point - I'd pre-emptively add this into a json object instead of just adding the value directly. This makes it easier to add metadata in the future, as it wouldn't be a breaking change.

You could also do that here as well, to keep the internal and external representations closer together. But, that is totally optional for here, but definitely something you should consider for the external representation.

[dsa0x]

Identity here is a map, but we are using it with the %s string directive. Do we want to jsonify that map first?

[dbanck]

Good catch! I've added a TODO to revisit this renderer once the cloud backend supports list runs.

[dsa0x]

Could we embed the PlanCommand in here, and use its methods PrepareBackend, GatherVariables, OperationRequest? Query is kind of a Plan anyway.

[dbanck]

Interesting idea! Right now GatherVariables is the only method with the exact same body, the other two are similar, but different. I'll check if GatherVariables can stay as is for passing variables to the query command in a separate PR

[dsa0x]

Great work! 💯