Determine if we want to make Worker object base class for instation of work functions in action nodes

[joshc-slac]

Want to be more procedural / uniform in how we:

• package work for execeution
• introspect on work being executed
• wrap up execution threads

Context / environment

Critical to resolve #27 before further work on this.

Specifically the notions start_work and stop_work could be helpful to be made universal to any "packaged work function" as well as uniform methods to introspect on status of process / offloaded work.

Notions of timeout of work function can also be encoded here.

A related point to BT action nodes is that we currently spawn work threads in the setup phase and signal execution in the initialization phase: https://github.com/pcdshub/BEAMS/blob/4be9dc569c857e275fe573ea19e35b926ec358a1/beams/behavior_tree/ActionNode.py#L42-L47

https://github.com/pcdshub/BEAMS/blob/4be9dc569c857e275fe573ea19e35b926ec358a1/beams/behavior_tree/ActionNode.py#L52-L58

Suggested Solution

Lets sketch out what it would look like to make: https://github.com/pcdshub/BEAMS/blob/4be9dc569c857e275fe573ea19e35b926ec358a1/beams/tree_generator/TreeSerializer.py#L88-L102

This type of work function of type Worker, should dovetail nicely with @tangkong 's efforts on #18

[joshc-slac]

Pros:

• Better ties packaged work to the lifecycle of the program:
  • Allows us to invoke "meta" work functions of start_work and stop_work, especially valuable if Processes run for entire lifecycle of application
• All our trees are currently "one shot" in that the Action nodes fall through when they achieve their goal once, this will allow them to reset and wait for re-initialization (in the py_trees sense)
• Further standardize how work processes are handeld Cons:
• Firmly ties together concept of ActionNode and Worker (not necessarily a bad thing, but stricter for sure)
• Entrenches us in a more library principic schema that will take slightly more than a glance to comprehend
  • Previously anyone familiar with multiprocessing.Process could immediately glean what would happen
  • I could make an analogy to pthread vs std::thread but i'll refrain