blueapi should have option to not start if not all devices can connect

[rtuck99]

Currently the behaviour is to still start even if some devices can't connect. However when Hyperion moves to blueapi, we will want blueapi to check whether devices can't be connected and refuse to start if this is the case. So we will need a configuration option or similar to allow this, while still allowing other consumers to have the existing behaviour

See

• with_dodal_module() should return connection errors #1235

Acceptance Criteria

• A configuration option exists to ensure beamline is fully connected at startup.

[DiamondJoseph]

See also #381 and the acceptance criteria including MX's case that didn't make it into the fix. I'm looking for other tickets where we discussed this before, I think we ended up with at least 2 classes of device: Mandatory that should always stop blueapi from starting (e.g. i19's access control?) and Optional that should not (e.g. movable sample environments). @tpoliaw is it possible to add that distinction to the new device manager?

Possible blueapi behaviour:

Unconnected device class \ blueapi config	Strict	Lax (Default?)	Override
Mandatory	Don't start	Don't start	Start
Optional	Don't start	Start	Start

[tpoliaw]

Adding an option to blueapi to abort if any devices fail to connect is possible although I have a feeling being in a subprocess might make it awkward to propagate back to the user.

There is currently no support in DeviceManager to distinguish between optional/required devices and I don't think it should block the current implementation being adopted. It does return a dict of device name to error though so we could potentially have a list of required devices in blueapi that must connect?