Luke/event driven script orchestrator

[LukeButters]

Background

[SC-82375]

Currently we only allow calling into tentacle client to run a script via the TentacleClient.ExecuteScript method. Although extremely simple it is not re-entrant. When we talk about re-entrancy we are considding the case the client gets turned off and on and wants to continue on. The deficiencies are:

• when using SSv1 could start a script a second time
• it will re-fetch all logs, rather than where or close to the point we left off from.
• it doesn't work well from an event driven orchestrator.

Results

This spikes out a tentacle client which can be driven by an event driven orchestrator which helps addresses those deficiencies.

In summary the changes are:

• The ObservingOrchestrator is no longer abstract and becomes a thing that "just" knows how to run the life cycle of the script.
• A new IScriptExecutor interface is created which allows driving script life cycle
  • This is now used by the ObservingOrchestrator
  • Could be used by an event driven orchestrator.
• The ScriptService Orchestrators which inherited from ObservingOrchestrator, now implement IScriptExecutor. They now focus on implementing the main stages of script execution following a single interface.
  • They are also responsible from converting from types the client of the client might use to the types that go over the wire.
  • They are responsible for their own "quirks" providing a straight forward interface to interact with.
• An AggregateScriptExecutor is created which:
  • On start script determines which of the other ScriptServices to use.
  • On the other methods uses the given CommandContext to determine which script service to use.
  • In doing so it can deal with calling the correct service.
• The ObservingOrchestrator is given an AggregateScriptExecutor
  • Which is called by TentacleClient.ExecuteScript
  • In this way the existing tests are able to exercise the AggregateScriptExecutor which is what an event driven orchestrator would call.
  • This reduces what an event driven orchestrator needs to implement to just what is done in ObservingOrchestrator