Look parameters don't contribute to Config cache ID

[michdolan]

I found this issue while working on ocioview. It appears that parameters beyond a Look's name don't contribute to the Config cache ID. Changing a look's process space and transforms produce the same cache result. For example:

>>> config = ocio.Config()
>>> config.getCacheID()
'429777eef17eb0f7c67e6d14e48d9a04:6001c324468d497f99aa06d3014798d8'
>>> config.addLook(ocio.Look("test"))
>>> config.getCacheID()
'63cee16e9b88f86dc9cdb903eae2c1e:6001c324468d497f99aa06d3014798d8'
>>> config.addLook(ocio.Look("test", transform=ocio.ExponentTransform()))
>>> config.getCacheID()
'63cee16e9b88f86dc9cdb903eae2c1e:6001c324468d497f99aa06d3014798d8'
>>> config.addLook(ocio.Look("test", processSpace="ACEScg", transform=ocio.ExponentTransform()))
>>> config.getCacheID()
'63cee16e9b88f86dc9cdb903eae2c1e:6001c324468d497f99aa06d3014798d8'

[doug-walker]

Thanks for the report Michael. It looks like there is a bug in:
void Config::addLook(const ConstLookRcPtr & look)

If there is already a look with the same name, the code replaces it but neglects to call:
AutoMutex lock(getImpl()->m_cacheidMutex);
getImpl()->resetCacheIDs();

So getCacheID() is not regenerating the ID, it's pulling the stale one from the cacheID cache.

This would be an easy bug for someone, adding the "good first issue" label.