Evaluate list resources

[dsa0x]

This PR implements the evaluation of list resources, then collects the results and stores them in the plan changes. It also

• Added a new Query boolean parameter to PlanOpts to indicate when a plan is being generated for a query operation
• Removed the dedicated walkQuery operation and integrated list resource execution into the standard walkPlan operation, but still being filtered out for now unless in query plan mode.
• The implementation leverages the existing planning infrastructure but modifies it to specifically target list-mode resources when in query plan mode.
• Added tests that verify various aspects of list resource operations, including validation, reference handling, state management, and errors.

Target Release

1.13.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.

[jbardin]

I'm not sure if we should be overloading this for list or not. In fact I wonder if these should be combined into the list object that also contains the resource objects, that way they are directly paired and we can choose to expose those via configuration for import.

[jbardin]

If we start evaluating this into normal configuration, I think we're going to want the vals to correspond to the same type as the list block object, rather than a tuple. That object could also give us a place to store the identities, which so have not been exposed in the configuration at all. This is why I mentioned that we need to complete the design of the configuration first, since the object type we use will follow that type.

[dsa0x]

I think we're going to want the vals to correspond to the same type as the list block object

I think what is being said here is to move the list block object construction from

terraform/internal/terraform/evaluate.go

Lines 925 to 944 in 9980cdf

	func (d *evaluationStateData) wrapListResourceValues(ident, obj cty.Value) cty.Value {
	ret := make([]cty.Value, 0)
	objIter := obj.ElementIterator()
	identIter := ident.ElementIterator()
	for objIter.Next() && identIter.Next() {
	objKey, objVal := objIter.Element()
	identKey, identVal := identIter.Element()
	if objKey.Equals(identKey).False() {
	panic(fmt.Sprintf("List resource has mismatched keys %s and %s", objKey, identKey))
	}
	ret = append(ret, cty.ObjectVal(map[string]cty.Value{
	"state": objVal,
	"identity": identVal,
	}))
	}
	return cty.ObjectVal(map[string]cty.Value{
	"data": cty.TupleVal(ret),
	})
	}

and do that here instead. Based on my understanding, either way would be fine. Is there any reason why the plan changes requires the exact type of the list result?