Move timeout handling to functions wrapped with AsyncStatus

[coretl]

I think the best place to apply timeouts for motion is in the *Motor.set function, rather than the caller to this function.

This PR shows what this looks like:

• Removing timeout handling from *AsyncStatus
• Calculating the timeout from velocity in *Motor.set and adding DEFAULT_TIMEOUT
• Making a mechanism to apply a timeout via observe_value for Mover.set

I think this makes things easier to use as you are not forced to bps.mv(motor, value, timeout=<something I have to calculate>), it fills in a sensible value for timeout itself. The only question I have is whether we should allow this timeout to be overridden.

@dperl-dls @callumforrester thoughts?

[callumforrester]

@coretl This seems very nice for motors but how does it affect your common garden signal?

The only question I have is whether we should allow this timeout to be overridden.

I can see the use case of "I want this motor to reach position a in n seconds otherwise my beamline is broken and I want to know about it" being a thing

[coretl]

@coretl This seems very nice for motors but how does it affect your common garden signal?

Not at all, they will still take set(value, timeout) which is handled by the underlying control system. It is up to the caller of Signal.set to supply a reasonable titmout. It is only the case of MyDevice.set which we are talking about here.

The only question I have is whether we should allow this timeout to be overridden.

I can see the use case of "I want this motor to reach position a in n seconds otherwise my beamline is broken and I want to know about it" being a thing

So "I want this to move within 2 seconds no matter where it was to begin with"? That's fairly easy to add as an override Motor.set(value, timeout=2). I'll do that.

[d-perl]

I think this is an elegant solution. The only real concern I would have had is about being able to override the timeout, that should definitely be possible. Is it still possible to wait forever on this?

[coretl]

I think this is an elegant solution. The only real concern I would have had is about being able to override the timeout, that should definitely be possible. Is it still possible to wait forever on this?

I've made the handling of Signal.set and Motor.set be the same so they take timeout: None | float | Type[CalculateTimeout] = CalculateTimeout, and this CalculateTimeout should give you a sane default

[d-perl]

lgtm