Don't use object pool for initialOldData, and properly recycle tempObject

[mrxz]

Description:
A temporary object was never released to the objectPool, causing a leak. After fixing this leak, some unit tests regressed. It turns out that the initialOldData provided to a component's update(oldData) is also leased from this pool. The pool however makes no guarantees about the state of the object. It might very well not be an empty object. (And due to the various leaks, it likely was an empty object)

This PR correctly clears and returns the tempObject to the pool and uses a constant frozen empty object for the initialOldData. This is a slight change in behaviour in case users mutate this object, but that was never correct and will now give an error.

Changes proposed:

• Correctly clear and recycle tempObject in Component update logic (updateCachedAttrValue)
• No longer use object pool for initialOldData for a Component's first update call

[dmarcos]

So I understand. use function should already calls clearObject. Is not this redundant?

[mrxz]

Oops, seems when cleaning up the PR I got clearObject and removeUnusedKeys mixed up in this place. The object pool does indeed "clear" the object, but the keys remains. Looking at the code again in more detail, it is actually safe here to have superfluous keys on tempObject in the subsequent utils.extend and extendProperties calls.

[dmarcos]

Same here. My understanding is that the use function calls clearObject. You mention

The pool however makes no guarantees about the state of the object. It might very well not be an empty object

What Am I missing?

[mrxz]

The problem is that clearObject only sets the keys to undefined. As a result the initialOldData can have zero or more keys present. This means that any update code doing things like Object.keys(oldData) or "someProp" in oldData ends up getting incorrect results.

Before there was enough leakage that you'd generally always get a fresh empty object from the pool.

[dmarcos]

Thanks!