Use ophyd_async DerivedSignals

[DominicOram]

Following bluesky/ophyd-async#661 there is now a DerivedSignal in ophyd_async that should be able to replace the hardware_backed_signal we have made in dodal.

Acceptance Criteria

• hardware_backed_signals are replaced by DerivedSignals from ophyd_async
• Tests still pass
• Any issue with the interface are fed back to ophyd-async

[Relm-Arrowny]

Can I pick this up, I am going to have to do it for i10 id and current amplifier later.

[DominicOram]

Sure, sounds good!

[DominicOram]

Note that you will have linting/test issues until #1143 is sorted

[Relm-Arrowny]

I have a quick try at making the change and I run into an issue, it appears the signal type is extracted from the type hint of the transformation function but at the moment it only support python build in type, if I try to use a custom type I get the following error:

  File "/usr/local/lib/python3.11/typing.py", line 2414, in get_type_hints
    hints[name] = _eval_type(value, globalns, localns)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/typing.py", line 395, in _eval_type
    return t._evaluate(globalns, localns, recursive_guard)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/typing.py", line 905, in _evaluate
    eval(self.__forward_code__, globalns, localns),
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<string>", line 1, in <module>
NameError: name 'ApertureValue' is not defined

which is caused by get_type_hints as ApertureValue is not define in _derived signal scope, I can make the device work by defining ApertureValue within _derived_signal.py.

To Reproduce
Run test_aperture_scatterguard.py in this branch.

Expected behavior
I think we expect to be able to use custom type in derived signals.

[DominicOram]

I think this can currently be done with the more complete API https://blueskyproject.io/ophyd-async/main/how-to/derive-one-signal-from-others.html#multi-derived-signal. I think it would be good to have this in the simple API if we can though, a common usecase we have is converting an enum of positions to/from motor values. Thoughts @coretl?

[coretl]

bluesky/ophyd-async#843 should fix it, please could you test?