Add helper function to observe multiple signals

[DominicOram]

In DiamondLightSource/hyperion#1450 we had the usecase where we wanted to monitor multiple signals and raise under one condition or stop monitoring cleanly under another. To aid in this it would be good to have an ophyd-async helper that observed multiple signals and gave you any updates that occured e.g.

async def pin_mounted_or_no_pin_found(self):
      async for signal, value in observe_signals_value(self.error_code, self.goinio_pin_sensor):
          if signal is self.error_code and value == self.NO_PIN_ERROR_CODE:
              # We didn't get a pin
              raise RobotLoadFailed(self.NO_PIN_ERROR_CODE, "Pin was not detected")
          elif signal is self.goinio_pin_sensor and value == PinMounted.PIN_MOUNTED:
              # We did get a pin
              break

[coretl]

Do we also want to rename observe_value -> observe_signal_value to make them more consistent?

[coretl]

Do we also want to rename observe_value -> observe_signal_value to make them more consistent?

Actually, I'm going to roll back on this, and say this ticket is just to add observe_signals_value

[ZohebShaikh]

We're deciding between two options for when to return the status:
Option A: Return status when the match signal changes to the expected value.
Option B: Return status when the signal changes to the expected value.
Both signals start at 0 and are expected to change to 1. The question is: Should we trigger the status return based on the match signal (A) or the main signal (B)?

[DominicOram]

You're asking in relation to set_and_wait_for_other_value, right? Not observe_signals_value, which I think this issue is more aimed towards? I didn't think observe_signals_value needed to be given any match values.

If it's about set_and_wait_for_other_value then I think we should return based on A as that's what the name implies and what most of my usecases are. An example use case:

• I set ACQUIRE to Do Acquire
• I want to know when the hardware is acquiring, for this I need to wait on ACQUIRE_RBV to go to Acquiring

ACQUIRE will probably go to Do Acquire immediately on set (depending on the callback logic on the hardware side I guess) but I'm only sure the hardware is acquiring when the AQUIRE_RBV says so, which could be a while later.

[ZohebShaikh]

Sorry should have mentioned it in #582