Hyperion refactor: Add lowest level FGS plan

[olliesilvester]

This issue begins moving Hyperion's plans into a more generic form inside this repo, see DiamondLightSource/hyperion#1067. The idea is to decompose Hyperion bluesky plans into common building blocks for any MX beamline to use. A beamline can then construct its specific implementation by building up these smaller generic plans. We should also look into using bluesky's 'prepare' command for device setup.

To kick off , I think it makes sense for the first plan added to be the lowest level plan for the fast grid scan. Since it is the lowest level, we need to make sure that this plan is as generic as possible, and that any beamline wanting to do a fast grid scan can use this base plan. It should have similar functionality to do_fgs() in hyperion's flyscan_xray_centre_plan.py. Its parameters should be:

• A list of devices. We should work out which devices are essential for this plan (is it just the FGS motor?), and leave room for optional devices (like zocalo).
• A generic 'device setup plan' (which could look like a two level plan, one to specify each individual device setup and one to specify the order/waiting requirements)
• A generic 'device tidy plan', to be used if there is an exception during the plan, or, optionally, at the end of the plan

The plan should:

• Set up all devices as specified in parameters and wait appropriately
• kick off the FGS
• Optionally wait for any optional devices (like zocalo)
• do a bps.complete()
• Do any tidy-up
• Be in a try block so tidy-up happens on an exception

EDIT: This is like a plan stub, so is not designed to be ran by itself. Therefore, this plan shouldn't consider setup or tidy-up

[callumforrester]

This design sounds good as-is. A few possibilities for discussion:

Since the aim here is to create building blocks, I think it's okay if they are not self-contained i.e. if it doesn't make sense to run them on their own. So you could take out the exception handling and expect that to be handled separately. Different users may just compose it in different ways e.g.

def do_fgs_and_cleanup(fgs: FastGridScan):
    yield from do_fgs(fgs)
    yield from cleanup(fgs)

def do_fgs_and_cleanup_on_error(fgs: FastGridScan):
    try:
        yield from do_fgs(fgs)
    except FgsException:
        yield from cleanup(fgs)

You could, of course, also provide the two plans above for convenience, but I think it's good to have a pattern of different compositions rather than lots of if statements in a plan. I fear if-heavy plans will get bloated as more and more cases are added.

I think there may also be scope for handling the optional devices separately, perhaps as a group that you then pass into do_fgs()? I'm not sure because I don't know exactly how they are set up and tied into the fgs operation.

I agree with looking into the prepare command to remove complexity, I might even suggest doing that as part of this exercise.