Decouple interlocks from shutter

[EmsArnold]

Fixes #2024

Interlocks should be decoupled from hutch shutters. This moves all potentially useful interlocks into interlocks.py.

Instructions to reviewer on how to test:

1. Check naming of interlocks
2. Confirm relevant beamlines connect (i03, i15_1, i19_optics, i24)

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.11%. Comparing base (0beeb31) to head (1e73829).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2033   +/-   ##
=======================================
  Coverage   99.11%   99.11%           
=======================================
  Files         327      327           
  Lines       12814    12819    +5     
=======================================
+ Hits        12701    12706    +5     
  Misses        113      113           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DominicOram]

Looks good to me, thanks. Might be worth a second pair of eyes from @DiamondLightSource/developers-mx-daq given it changes their beamlines a little too.

[CoePaul]

it seems counterintuitive here to have an OR

a) usually something safety related will only say yes after a compound AND
( I mean that's basic / fundamental / vital )

b) the implication is that this one piece of code
is maybe covering two types of hardware and doesn't know which hardware type ( sub-genre whatever )
it is representing so has to go and ask OR type questions to cover all bases

In a situation where we are using a bit of OO
this is exactly where I'd expect one child / grandchild class to cover each hardware type in a 1:1 mapping even if it were only to override this one method

Software people will throw up their hands in horrror
but really the world should not revolve around the axis of software convenience
IMHO

[EmsArnold]

From my understanding, OK is when the valve/shutter is open AND the interlocks are all okay, whereas Run Ilks OK is when the interlocks are all okay and thus the valve/shutter can be operated. The only enum specific to a device is actually Failed, which is only used for fast valves.

I think this is then a third option c) the idea is to check whether the device is safe to operate (open or closed), whereas the enum is specific to either opening or closing? I suppose the fix then would be to check if something is open and can be closed, or closed and can be opened?

[EmsArnold]

@CoePaul mentioned offline:

I take that as a sign that my wondering about names like PSSInterlock
or IntPLCSomething are ill-positioned in time and scope

I thought camel case was all like

PssInterlock
and
IntPlcSomething

acronyms were supposed to be only capital on the first letter
a constant bug bear in GDA is how much UDCSomething there is when it should have been
UdcSomething ... are we really repeating that inconsistency-for-the-heck-of-it in dodal ?

I wasn't aware of the history, but am happy to change if that's the convention we're keeping to. It seems to go against pep8, so we may want think about adding this decision (and the reasoning) to the dodal style guide.

[DominicOram]

It seems to go against pep8, so we may want think about adding this decision (and the reasoning) to the dodal style guide.

I would strongly advocate for maintaining the PEP8 rules and having acronyms as all caps. This also matches the style of the standard library e.g. HTTPStatus or BytesIO

[EmsArnold]

A further note that this change will require any plans which reference HutchInterlock to be renamed to PSSInterlock, and any which reference BaseHutchInterlock to be renamed to BaseInterlock

It looks like HutchInterlock pops up a few times in mx-bluesky