Split the Scheduler class into single-purpose pieces
Context
After implementing the ability to watch job state in !229 (merged), the purpose of the monolithic Scheduler
class is somewhat diminished. Previously having RWAPI and REAPI functionality in the same class was useful for orchestrating communication of changes back to the peers with minimal plumbing.
Now that the communication is handled separately to the updates, there is no need to have a single class containing now-unrelated methods for handling requests from both peers and workers. Instead we should split the Scheduler
into at least two classes, one for Execution
related methods, and the other for BotsInterface
methods.
It may make sense to simply move each part into the respective instance implementation, since DataStoreInterface
largely works as the layer of abstraction that Scheduler
used to provide.
Acceptance Criteria
The Scheduler
class is gone and its functionality is moved to more sensible places.