Business template have some logic to keep uids when updating objects:
during installation, when an object is modified, business template first
remember the uids for this object and all its sub-objects,
replaces this object with the new version then recursively set the uid
on updated objects, so that updating an ERP5 document by business
template does not change its uid because this would break catalog.

When an object containing sub-objects is updated, it becomes a new
object in ZODB and sub-objects of the previous object are set as child
of the new object. This works even if the case of sub-objects being
instances of ZODB Broken class, except that the step where we restore
the uid fail as it's not allowed to modify a broken object.

Instead of unconditionnally setting the sub-objects uids, check that we
actually need to set it, because if it's already the expected value then
we don't need to touch the object.