libminkadaptor: fix memory object leak in callback object dispatch

[Jiaxing Li (jiaxli-QC)]

The output (OO) object references a MINK callback returns from a successful invoke are new references owned by this dispatcher and must be released. They can't be released inline in the dispatch since QCOMTEE marshals and sends the response only after the dispatch returns, so they are stashed in struct qcomtee_callback_obj and released in qcomtee_callback_obj_cleanup(), which QCOMTEE invokes post-response. Without this the memory object carrying the TA image returned by the TA autoload callback leaks on every successful load.

Reset num_output_objs at the start of each dispatch so a later cleanup never acts on a previous dispatch's stale state, and clear num_output_objs once after the release loop (not inside it, which would stop after the first object and leak the rest for multi-OO callbacks).

Also NULL each allocated_bo slot after free so a repeat cleanup on the reused callback object can't double-free the same buffer.

Fix-issue: #9

[Harshal Dev (harshaldev27)]

This is completely wrong. The underlying issue here is that when CRequestTABuffer_get(..., Object *appElf) callback is called, it allocates a memory object within the createTAImageReader() call, a reference to which is copied to *appElf pointer, and then the only reference that CRequestTABuffer_get() has to the object is destroyed when delete(TAImage); is called before exiting CRequestTABuffer_get(). So we have no way to call Object_release on the memory object allocated. The memory object reference however still lives in the libqcomtee's object-list. It can only be free'd if the CBO executes an explicit Object_release call.

So, we have two options:

1. We need to keep references to the allocated memory object within CRequestTABuffer which can be free'd when the deinit() defined in TAAutoload.cpp calls Object_ASSIGN_NULL(requestTABuffer);.

2. A better approach to this, is to add support for an error() or notify() callback in CRequestTABuffer which can be invoked from mink adaptor which already gets the notification from qcomtee when a successful CBO response has been provided to QTEE. Since in this particular use-case, once we have shared the memory object to QTEE after placing the TA binary inside it, QTEE will never come back and ask us to operate on it again, it is safe to release this memory object reference once we are done with sending the MO back to QTEE.

[Harshal Dev (harshaldev27)]

Please make the changes as requested.