This reverts commit 0c29acc106ca774e230c8ef45694c8bffd166b69.

This reverts commit e56f8d58b80334256085907961aac9ca9f56f125.

node.default['foo'] = node['bar'] need to have node['bar'] have its
cache vivified otherwise we potentially get an empty hash or array.

in the case of hashes, the assignment must have been walking though
the values with #each or something which poked the cache on the target
hash which caused it to vivify, so this bug only affected Arrays
where the AttrArray initializer likely did a quick-n-dirty copy of
the internal structure of the ImmutableArray which was empty.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Replaces the one-big top level deep merge cache with individual deep
merge caches in every container.  The Immutable container state becomes
the deep merge cache.

- Does not use a pure decorator style approach since that failed before
because of ruby internals breaking things like `===` and `=~` on
decorated objects, so we inherit (ultimately from Hash + Array).
- The state being the container state is useful in ruby since APIs on
Hash and Array poke around in internal state to make things fast.  If
we inherit from Hash/Array but don't have the correct internal state
things go wonky.
- Throwing away the internal state is equivalent to flushing the cache.
- Since we throw away all linked objects when we do that, we flush at
every level below the level being flushed (which is correct semantics).
- If a user has a pointer to an old immutable object from a sub-level,
that isn't mutated so the old object still contains the old view of
the data (which I think is correct, although I have some doubts that
its necessary, but it came along free for the ride).
- When we reset the cache we do mutate the cache being reset, which
might change data in held references.  If this becomes an issue the fix would
be to reset the cache at the level above by creating a new, "empty"
ImmutableHash/ImmutableArray object and inserting it into the
deep_merge_cache datastructure instead of clearing the internal state
of the child object.  I don't know practically how anyone would hit
this, though, so would prefer to wait on doing that work until we see
an actual bug report.
- Because of the way ruby pokes around internally there's some
weirdnesses like the pre-generation of the cache for all the values of
a subarray when #each is called, which is due to the way that ruby
walks through array-serialized hashes when called like:
`Array#each { key, value| ... }` (which is an undocumented(?) thing
in ruby).

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

nod to @jaymzh for finding this one.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

similarly to fixing to_hash.

kind of feels like we should return a VividMash instead of a Mash
here, to get a writable thing that behaves like an attribute...

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

previously to_hash allowed mutating non-container elements, now
they get properly dup'd.

fixes a 2.5 year old pending spec test.

also fills out the API so that there is to_h/to_hash/to_a/to_array
instead of the weird mix-and-match we had before.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

So again the reasons why we break this:

- node.class vs. node['class'] kinds of problems
- adding node#foo to Chef::Node as an extension to the API and
  breaking node.foo meaning node["foo"] (we can't make exensions
  to that class without possibly breaking someone)
- crazy things like the old CHEF-3799 issue in the old ticketing
  system where IO#puts in ruby blindly calls #to_ary on stuff and
  expects it to raise -- whereas we would potentially autovivify
  a 'to_ary' hash key and return nil which breaks the world.

This also has caused issues with the hashie gem and they've gone to
spamming warnings by default to try to deal with it:

https://github.com/berkshelf/berkshelf/issues/1665

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>