Environments containing applications with circular references can't be deleted

[Alexander Tivelkov]

If the model object contains circular references (for example, objectA owns objectB, and at the same time ObjectB has an output property which has got assigned to the ObjectA in runtime), then the model cannot be deserialised for subsequent deployments of deletions of the environment.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/220757

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/220757
Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=024ac109ef86a547dab63acbe0e8c8d0c11b5fcd
Submitter: Jenkins
Branch: master

commit 024ac109ef86a547dab63acbe0e8c8d0c11b5fcd
Author: Stan Lagun <email address hidden>
Date: Sun Sep 6 01:09:01 2015 +0300

    ID references made model not able to load in 2 passes

    ObjectStore used to replace object factories with actual objects
    only after 2 passes instead of after first pass as it was before then.
    Until that happened object could not be obtained from outside
    despite it was already created by the 2nd pass so ID reference
    resolution that happened on the second pass failed.

    With this fix ObjectStore doesn't tries to hide partially-initialized
    objects anymore. So if object A references object B by ID
    it may get B after B has been loaded but before its .init was called.
    That's not a problem because we just loading (relinking) model
    and do not depend on anything that could be initialized in B's .init.
    However because B is not owned by A and A is not owned by B
    it may happen that .init of A will be executed prior to .init of B
    so if A's initializer will see object B that wasn't initialized yet.
    Generally this is unavoidable because there may be circular
    references. So there were 2 options: either to do more that 2
    passes and try to to avoid such situations for cases when
    there are no circular references or just require classes not
    to do anything with objects they don't own from .init.
    Because .init is also called from GC and should not have
    side effects at all the second options was chosen but
    we may reconsider this in the future

    Closes-Bug: #1492640

    Change-Id: Id38a780f9084323f0806b044262aa3b89eb5da74