chore(lib): Standardize IResolvable usage

[jsteinich]

The goal of this PR is to establish consistent usage of IReolvable when working with attributes of Terraform elements by looking to the AWS CDK for guidance and making improvements where appropriate.

Work already done:

• Update TerraformLocal to use refs similar to other types
• Split interpolation and getString within TerraformModule for future refinements and possible manual escapes.
• Stop casting booleans. Will fix additional cases of csharp: Amazon.JSII.Runtime.JsiiException Expected a boolean, got "a" (string) #960

IResolvable usage:

TF Type	CDKTF CURRENT	AWS CDK	CDKTF PROPOSED
string	string	string	string
number	number	number	number
boolean	boolean | IResolvable	boolean | IResolvable	boolean | IResolvable
object	object	object | IResolvable	object
string[]	string[]	string[]	string[]
number[]	number[]	number[] | IResolvable	number[]
boolean[]	boolean[]	Array<boolean | IResolvable> | IResolvable	Array<boolean | IResolvable> | IResolvable
object[]	object[]	Array<object | IResolvable> | IResolvable	object[] | IResolvable
Record<string, string>	{ [key: string]: string } | IResolvable	{ [key: string]: (string) } | IResolvable	{ [key: string]: string }
Record<string, number>	{ [key: string]: number } | IResolvable	{ [key: string]: (number) } | IResolvable	{ [key: string]: number }
Record<string, boolean>	{ [key: string]: boolean } | IResolvable	{ [key: string]: (boolean | IResolvable) } | IResolvable	{ [key: string]: (boolean | IResolvable) }
Record<string, object>	{ [key: string]: object } | IResolvable	{ [key: string]: (object | IResolvable) } | IResolvable	{ [key: string]: object } | IResolvable
Set	string[]	string[]	string[]
Set	number[]	number[] | IResolvable	number[]
Set	boolean[]	Array<boolean | IResolvable> | IResolvable	Array<boolean | IResolvable> | IResolvable
Set	object[]	Array<object | IResolvable> | IResolvable	object[] | IResolvable
dynamic	{ [key: string]: any }	{ [key: string]: (any | IResolvable) } | IResolvable	{ [key: string]: any }
list<map>	may be broken	Array<{ [key: string]: (string) } | IResolvable> | IResolvable	{ [key: string]: string }[] | IResolvable
set<map>	may be broken	Array<{ [key: string]: (string) } | IResolvable> | IResolvable	{ [key: string]: string }[] | IResolvable
list<list>	may be broken	string[][] | IResolvable	broken
list<set>	may be broken	string[][] | IResolvable	broken
map<list	may be broken	{ [key: string]: (string[]) } | IResolvable	broken

The general rule is include IResolvable when no token type is available and when not using custom structs.

Changes from AWS CDK:

• Don't use IResolvable for custom structs (labeled as 'object'). Since Terraform doesn't allow passing entire blocks, I'm not sure why we would need these to be resolvable ---Use IResolvable when only an interface is generated
• Create a token type for number[]. They are more common in Terraform and can combine string[] and number token techniques
• Create a token type for boolean[]. This one is debatable, but a token could be created using binary encoding
• Create a token type for Record<string, *>. Can use a special string token key in the map to indicate the entire map is a token. Only make for core types and expand others to use IResolvable similar to AWS CDK since jsii requires exact typing.

Other areas of consideration:

• Should count on resources being just a number? Probably yes since we can use a token and number translates to other languages better.
• Should functions use IResolvable? The AWS CDK would say no as it hurts other language support. Since chaining functions is more common in Terraform, we probably want to use it. Might be nice to make available for all, but could also do case by case analysis of which functions are likely to be chained. --- Match with other rules as much as possible.

[jsteinich]

Thanks for taking a look @DanielMSchmidt. @skorfmann @ansgarm any thoughts on the proposed changes? This may not make the next release, but I'd definitely like to see it in the following one.

[ansgarm]

Thanks for the draft, @jsteinich 👍

Should count on resources being just a number? Probably yes since we can use a token and number translates to other languages better.

The AWS adapter uses the output of a Terraform function here:
https://github.com/hashicorp/cdktf-aws-cdk/blob/c76da087c38d55551f73faa8934e4457f778dfc8/src/aws-adapter.ts#L165-L169
However (as you noted) this output could be wrapped in a Token.

Create a token type for boolean[]. This one is debatable, but a token could be created using binary encoding

Hehe, nice idea. But, yeah, debatable 😄

Maybe there are other specifics of the current implementation used in the AWS adapter, but I've not found further ones and I could always resort to overrides should there be some 😄

[ansgarm]

This is some stellar work @jsteinich 💯

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.