Consider removing constraints from collected ref. origins

[radeksimko]

Context

Currently we collect constraints closest to the reference. For example, given attribute schema

{

	"foo": &schema.AttributeSchema{
		Constraint:  schema.LiteralType{Type: cty.List(cty.String)},
		IsOptional:  true,
	}
}

and relevant config

foo = [var.bar]

we collect var.bar as origin with cty.String constraint.

This enables us to be more precise when matching origins against targets, i.e. we can filter out any clear mismatches, such as if var.bar of type cty.Map().

The benefit of such accurate matching was questioned from both UX and maintenance burden perspective.

hcl-lang/reference/origin_local.go

Lines 20 to 26 in 9c3a246

	// Constraints represents any traversal expression constraints
	// for the attribute where the origin was found.
	//
	// Further matching against decoded reference targets is needed
	// for >1 constraints, which is done later at runtime as
	// targets and origins can be decoded at different times.
	Constraints OriginConstraints

Importantly we still need to distinguish between type-less and type-aware references, such as

depends_on = [ aws_instance.foo ]

VS

value = aws_instance.foo # object

but we should be able to still do that without having to distinguish between different types. i.e. it should be sufficient to know that a reference is type-aware, but not what exact type it is.

Proposal

• Loosen up origin/target matching logic to avoid type matching
• Expose this under feature toggle to all users, first opt-in, then opt-out
• Remove matching logic and OriginConstraints entirely