closes #7738

The root cause here is that there's a difference between doing

Chef::Node::VividMash.new( <another VividMash> )

And:

Chef::Node::ImmutableMash.new( <a VividMash> )

The former short circuits and does no work in convert_value.  The
latter will not short circuit and does the proper work to dup
and convert the value argument.

Since we build an ImmutableMash now, we do not need to wrap it
with the extra immutablize() call.

This should be perf neutral or very, very slightly better perf.

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

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

absolutely hard requirement on the fixes that went into chef-config 2.2.11, so the
floor of that gem is bumped up.

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

these get monkeypatched in by gems which are included in ChefDK
and cause those tests to break.

kind of unpleasant workflow, but this is doing its job correctly.

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

This reverts commit 0c29acc106ca774e230c8ef45694c8bffd166b69.

This reverts commit 5b17173847fe3e6d2a976fecad065952c801522e.

This reverts commit e24565b571e97275d39fcf7c97afc7dd6e1a37c4.

This reverts commit 9fe57c38a57135c7bd29ff05a1c7839a4d30c38c.

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>