Dont signal occurrence if client call not active

[ni-sujain]

fix for issue #217

The issue is that client can run into a situation where an inactive client call(e.g. due to vi aborts) will end up signaling the lv occurrence from async thread for an active client call(occurrence is getting re-used) and "wait for occurrence" unblocks without reading the response from server and we will see no response for the active call.

The fix involves clearing the active client calls list on vi abort and signal occurrence only when the current call is active. This fix will work for most cases but it still can run into some race conditions.

Alternatives considered:

• Somehow reset the occurrence on vi abort. Could not find a way to do this. Even if a signal the occurrence in ClientCleanupProc it doesnot work.
• Reset occurrence before we run ClientUnaryCall CLFN node. Tried Wait on occurrence primitive with zero timeout, Set occurence primitve but they also did not work. as even if we reset, the async c++ can signal before we go inside new ClientUnaryCall CLFN.
• Do a wait() on blocking client call but this takes away some async behavior.

testing:
I tried with the attached example from the issue. It runs fine.

[shivaprasad-basavaraj]

We should add this scenario as an auto test as well.

[shivaprasad-basavaraj]

Should we name this method CheckActiveAndSignalOccurence to signify that we will fire the occurrence only if the client call is active?

[ni-sujain]

Note: This PR still need some work. There are test failures for streaming cases

[drjdpowell]

Just a FYI, but this is another reason (beyond #207) to be wary of using Occurances rather than a Queue. Queues, like most LabVIEW refnums, can be created and destroyed, and have a lifetime tied to the creating VI hierarchy, meaning they are cleaned up automatically when the VI is aborted, and any refnum passed to other code becomes invalid (yet safe to call). This prevents all kinds of problems and can allow race-condition free code.

Occurances are seemingly simple low-level things, but they can be tricky to use, because they don't have a controlled "lifetime". You can't "clean it up and create a fresh one" to solve your corner case like an aborted VI.

[ni-sujain]

See PR #251