Investigate why Hyperion tries to connect to devices after already being connected

[olliesilvester]

Hyperion raised a timeout error when an ophyd_async device failed to connect in time. After looking at https://graylog2.diamond.ac.uk/messages/logs_8652/cd356670-cc46-11ee-a034-1866dafadc6c, it looks like Hyperion was running its setup plans when it had already been running for a while. This part of the code should only be running once, when Hyperion is first started

[DominicOram]

The issue seems to be that when we run device_composite_from_context we also call _wait_for_connection(device=device). Which calls connect on the ophyd and ophyd-async devices. In ophyd if the device is already connected this does nothing. In ophyd-async it will make a re-connection. We can discuss with the collaboration if this is expected behaviour but in the mean time we don't need to call _wait_for_connection(device=device) as all underlying devices should already be connected when we do setup_context (in production anyway as we always run with skip_startup_connection=False)

[DominicOram]

Linked PR stops us doing the reconnect but breaks Hyperion if skip_startup_connection=True. A proper fix needs some discussion with ophyd_async as ideally they would match the behaviour of ophyd or at least let us see if a device is connected then decide not to connect it. If the behaviour in ophyd_async does not change we will need to pass around skip_startup_connection and use that to decide whether we should be calling the connect or not