Occasional odd message from check_topup

[DominicOram]

We have seen an occasional log of:

[32m[I 250129 09:50:11.740 check_topup:67] 
                Exposure time of 0.0s below the threshold of 120s.
                Collection delayed until topup done.
                �[0m

This seems odd, why would the exposure be 0?

https://graylog.diamond.ac.uk/messages/graylog-daq-mx-hyperion_21/6e98dcd1-de26-11ef-ab61-32b1fc48808c

Acceptance Criteria

• The log gives the correct exposure

[rtuck99]

Seems like this is true only for gridscans, for rotations we report non-zero values.

do_fgs._wait_for_zocalo_to_stage_then_do_fgs() invokes

    yield from check_topup_and_wait_if_necessary(
        synchrotron,
        expected_images * exposure_sec_per_image,
        30.0,
    )

The total exposure time is obtained from expected_images * exposure_sec_per_image which are obtained from

expected_images = yield from bps.rd(grid_scan_device.expected_images)
exposure_sec_per_image = yield from bps.rd(detector.cam.acquire_time)

so it's likely that one of those things is zero

[DominicOram]

Added some logging which shows that expected_images is not getting set correctly. Issue looks to be that get_value on ExpectedImages is not getting called, changed to use create_hardware_backed_soft_signal on the beamline.