DO NOT MERGE: test PlanResourceChange handling of map creates

[t0yv0]

Noticing that rolling out PlanResourceChange to AWS causes dirty refreshes of the form where "tags" are changing from "null" to "{}".

It appears that what's changed is actually how Creates work, that is {} from Read is fine but null from Create is not. Before PRC we would have Create return tags: {}, but after PRC it returns tags: null instead on a program that does not set tags at all.

Still investigating... it appears that AWS provider does set tags to the empty map but they proceed to disappear in normalizeNullValues:

normalizeNullValues
 dst: cty.MapValEmpty(cty.String)
 src: cty.NullVal(cty.Map(cty.String))
 apply: true
 finval: cty.NullVal(cty.Map(cty.String))

This behavior seems to match TF but in the case of TF this form of dirty refresh is invisible and subsequent terraform apply calls remove the problem.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.21%. Comparing base (7677b6e) to head (deb0028).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2063      +/-   ##
==========================================
- Coverage   61.53%   61.21%   -0.33%     
==========================================
  Files         334      337       +3     
  Lines       45056    45177     +121     
==========================================
- Hits        27725    27654      -71     
- Misses      15803    16003     +200     
+ Partials     1528     1520       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[t0yv0]

Empty lists and sets affected equally to maps. Not affected curiously if the attribute is Computed :) CC @VenelinMartinov

[VenelinMartinov]

I'm a bit confused about this - shouldn't Create only be allowed to set Computed properties?

[t0yv0]

That's an excellent point. I think that's exactly right documentation wise, but apparently this property is not enforced by the framework. The bridge is doing something really special because we changed how tags property work to remove Computed=true from the original upstream. I can confirm however that tagsInterceptor does in fact call rd.Set() in the bridge. And that seems to take effect and work.

[t0yv0]

We wrapped this investigation up in #2065