Implement checking of FrameReceiver status before starting acquisitions

[GDYendell]

Previously the FrameProcessorAdapter performed checks via the FrameReceiverAdapter that the frameReceiver has all of its free buffers available to avoid confusing failures. This was removed here.

The generated start_writing method should be disabled (.enabled = False, e.g. here and a @command method added to FrameProcessorController the does the checks and then calls the start_writing method, which is still available internally, just not exposed to the transport layer (I think).

Acceptance Criteria

• FrameProcessorAdapterController does not allow start writing if frame receiver status is bad.

[GDYendell]

@ajgdls would it make sense to, instead of adding a mechanism for the FrameProcessorController to query the FrameReceiverController free buffers, add a start writing command to the OdinController?

I think this is conceptually what this coupling between the two is saying - you can't do start on the fp in isolation, you can only do start on odin (fp + fr). Plus if we ever give the meta writer a start button instead of handling arbitrary acquisitions, the top level start would also poke the meta writer.

[ajgdls]

Looking at the OdinController class I think this would be possible. However, the class loads specific OdinAdapterController classes from an input list of adapters. The names of the adapters are not guaranteed and neither is the quantity of any particular adapter type (although in reality there will often be 1 called FR and 1 called FP).
This means that this class will need to maintain a list of FR and FP controller classes registered based on their type and then interact with these when the query and command needs to be executed.
This is entirely possible, but is it an appropriate way to handle this requirement.

My vote would be let's try it and see how it looks. If it ends up being too ugly then we could look at other options.

[GDYendell]

I think what we need is a specific OdinController that explicitly defines that it has fp, fr and meta adapters. If when the control server is introspected it doesn't meet this definition, it raises an error. This would mirror closely what the ophyd PandA device does, here.

This is where that logic is done and it is pretty complicated. I might ask Eva to write the equivalent in FastCS as she knows how that works.

This however means that this is another ticket blocked waiting for core changes...