Ophyd-async implementation of optical components for i22

[DiamondJoseph]

GDA knew about upstream devices, could control them and automatically add them as monitors to scans, propagating their data through to NeXus files. Equivalently in blueapi, we want to control, monitor and propagate data about these devices.

i22 has these components, many of which should be generic enough to be re-used for other beamlines:

Device	Physical Axes	Derived Axes
Aperture	X_pos, Y_pos
Slit	X_plus, X_minus, Y_plus, Y_minus	X_centre, Y_centre, X_size, Y_size
Shutter	Shutter (OPEN or CLOSED)
Double Crystal Monochromator	Bragg Angle, 1st Crystal Roll, 2nd Crystal Roll, 2nd Crystal Pitch, Perpendicular Distance, X-Translation	Offset, Energy
Quad Beam Position Monitor	X, Y
Horizontal Focussing Mirror	Fine Horizontal	X, Y, Pitch, Roll, Yaw
Vertical Focussing Mirror	Fine Vertical	X, Y, Pitch, Roll, Yaw
FSwitch	X, Y, Pitch, Yaw

Acceptance Criteria

Required for NXsas definition desired on i22, and therefore should be either present or resolvable from the signals on the defined devices, or defined in some way as to be recoverable from a metadata service/database:

Device Type	Read Fields	Configuration Fields
Insertion Device	gap	poles, length
Monochromator	energy, energy errors
Monochromator Crystals		usage, type, reflection, d_spacing
Slit	x_centre, x_gap, y_centre, y_gap
HFM	incident_angle	type
VFM	incident_angle	type
F-Switch	number_of_lenses (?- may be denoted wrong)	lens geometry, cylindrical (TRUE/FALSE), lens_material

[callumforrester]

From discussion with @DominicOram, we identified existing versions of some of these devices in dodal which could be ported to ophyd-async to avoid duplication. Will make separate issues for porting each.

[callumforrester]

@DiamondJoseph Unsure if F-Switch is needed in the NeXus file, would you mind double-checking?

[DiamondJoseph]

It's not in the requirements for i22

Edit:
I am blind and bad and dumb, it is on there.

[callumforrester]

Aperture covered by #391

[DiamondJoseph]

Still required for acceptance criteria is just #587

Nice-to-have devices that aren't explicitly called out in the NXsas definition:
Aperture, Shutter, Quad Beam Position Monitor

[DiamondJoseph]

@stan-dot You can close this ticket as a duplicate of #587 which is better scoped to remaining requirements if you'd like

[stan-dot]

closing as a duplicate of #587