context/data: memleak due to API (mis)use

[bradh352]

Memory management is a foreign concept to python in general, however it
appears DNode and Context require .free() and .destroy() to be called,
respectively, to avoid a memory leak.

This seems easily avoidable by simply attaching a destructor to the
class so the python garbage collector can clean up automatically when all
references go out of scope.

We add a reference to any DNode object derived from another DNode object
(but not duplicated) so we can determine if we are allowed to be the one
to destroy the DNode cdata, as well as to keep proper reference counting
in case the owner goes out of scope but a dependent reference is still
in scope.

This change should also be compatible with existing integrations which may be
aware of this as it sets the internal cdata reference to None and checks
it to ensure it doesn't run the cleanup again. That said, I think calling
DNode.free() in this case is still risky since there are no checks to
ensure this is truly valid like the destructor does.

Signed-off-by: Brad House (@bradh352)

[bradh352]

guess I need to dig into the test system to see what it doesn't like about this....

[bradh352]

tests are getting further, but it looks like I'll need to dig deeper, this is fairly hard to debug since its crashing in C code, not sure how to dereference the python line that causes the crash or if its in the garbage collecting process.

likely i need to extend the reference linking even further to additional child structures from DNode, and possibly also enforce each DNode references the Context it is associated with, it looks like in a few places that may not be true.

marking as a draft, going to put this on hold as I've sprinkled some .free() and .destroy() in the implementation I'm working on for now ...
bradh352/sonic-buildimage@5019c24