Refactor bluesky-queueserver integration to work with any optimizer

[thopkins32]

Currently, the bluesky-queueserver integration is handled via a custom Agent that is specific to Ax optimizers. This can be reworked to use Blop's protocols rather than integrate only with Ax optimizers.

Here is the proposed refactor:

• Remove blop/ax/queueserver_agent.py
• Create blop/queueserver.py file with 3 classes:
  • blop.queueserver.ConsumerCallback essentially unchanged
  • blop.queueserver.QueueserverClient
    • Handles interaction with REManagerAPI
    • Handles callbacks with RemoteDispatcher and ConsumerCallback
  • blop.queueserver.QueueserverOptimizationRunner
    • Runs the optimization loop through a Bluesky queueserver
    • Initialized with a blop.protocols.OptimizationProblem and a QueueserverClient
    • run() method that sends optimization iterations to the queue
• In blop/ax/agent.py create a new agent that has a nice interface to the runner

Benefits of doing this are:

• Separation of responsibility for interaction with the queueserver and managing the runtime (more modular code)
• Enables the use of any optimizer (not just Ax) with the queueserver
• Maintains the agent interface (that uses the new runner under the hood)

User supplies:

• ZMQ addresses for communicaton
• Evaluation function
• Ophyd devices used (or rather their names)
• DOFs / Objectives / constraints / etc.
• Acquisition plan (or rather the plan name)

I may create a new OptimizationProblem dataclass that requires the actuators, sensors, and acquisition plan to be str rather than Python objects. The instances of the Python objects won't be available to the user, only the names of these objects would be.

[thopkins32]

@whs92 Here is what I am proposing for a refactor. I'll write up a PR soon and tag you on it for review.

[thopkins32]

Also, I think I may be able to get around the need for searching for a custom UUID in the evaluation function. If Blop attaches some metadata to the plan submitted (e.g. "blop_correlation_id": uuid()) and then filters that within the callback, then we should avoid the issue of random plans from the queue being consumed by our callback.

This should give us the UID of the correct Bluesky run directly so you can access it easily from Tiled.