Algorithm Problem Backchannel

[BernhardWerth]

For some stateful (e.g. dynamic) problems it is desirable to have more information about the current state of the algorithm than the current IStatefulItem-Interface. I extended IProblem with the ability to listen to IAlgorithm-events.

[gkronber]

Thank you for this PR. I have reviewed your changes and they look alright. A unit test is included which is positive.

Could you please give a longer explanation with examples why this functionality is needed. How can we use this 'back-channel' for something that is currently not possible?

[BernhardWerth]

Example: I would like to create a dynamic optimization problem with an environment inside that requires e.g. an asynchronous thread to apply changes to the problem. (The discussion about why I would wish to do this is contentious and probably better held elsewhere.)

If I use an IStatefulItem to do this, this thread actually starts too early as InitializeState is called in OnPrepared rather than in OnStarted wasting quite some resources when considering e.g. a large Experiment. (in the same vein I probably want to pause the environment when the algorithm pauses)

Alternative Appraoch: We could extend the IStatefulItem-interface, but this would

• potentially require more empty implementations of the new method (considering some branches/old tickets) than Problem, UserDefinedProblem and OKBProblem and
• need to be done again should the need for a more fine grained state management.

Example 2: One could prevent running two or more different algorithms simultaneously on the same problem instance. E.g. problems with internal surrogate models might even be made thread-safe to allow the use of a ParallelEngine. But inadvertently attaching the same problem instance to two algorithms (which is totally fine for many stateless problems) "bleeds" information between them and would be fairly hard to detect.