[WIP] Thread safety and Coupling between Workflow/Plugin

[pskrunner14]

Changes [WIP]

1. Thread Safety

SLU Service/API generally has a single Workflow object in memory that is responsible for execution of plugins across all requests and maintaining their respective state (input/output) variables. While that in itself is not problematic, Workflow is writing to shared state variables. Since it also has to accommodate requests from concurrent threads, it is doing so with the help of a synchronisation primitive lock order to prevent a race condition. Thread safety in this context is a solution to a problem we invented.

Additionally, Workflow implements reset and flush auxiliary functions for maintaining state variables.

This MR removes the original problem i.e. writing to shared state variables and strips all the bloat needed for synchronisation.

2. Coupling between Workflow/Plugin

There is tight control and data coupling between Workflow and Plugin. This is most evident in set function implemented by Workflow that syncs the output of a plugin with the internal state variables thereby compensating for the input/output asymmetry of a plugin utility function. However, set is called from a plugin base method __call__. Since change 1 moves internal state variables out of Workflow, Plugin no longer has to depend on it to maintain symmetry.

This MR moves the set function to Plugin and reduces it's coupling with Workflow.