Add CI job that fails PRs if tests are taking >1s

[DominicOram]

All unit tests should be fast running and so not take >1s each. If they are taking longer it is most likely due to an issue with poor mocking. To make sure we enforce this we should add a CI check on a PR that confirms that no tests individually took too long.

The durations can be found with pytest -m "not s03" --durations=0 but this isn't very machine readable so it may be worth a look around to see if we can get them out in a nicer way

We should use the approach discussed in bluesky/ophyd-async#729 (comment). Then feed it back into the copier template

Acceptance Criteria

• CI blocks PRs where an individual test is taking longer than 1s

[DominicOram]

@callumforrester, thoughts on doing something similar for dodal?

[callumforrester]

I like this idea as long as it's reliable, not sure how consistent CI CPU time is, does it vary a lot depending on cloud load? If so, we could actually profile the tests. But regardless I'm keen on this.

[DominicOram]

Added DiamondLightSource/dodal#1003. Anecdotally I think the test timings are pretty reliable. I think the best way to confirm this though is just implement the check and see how many false positives we get

[callumforrester]

For both this and issues #633, I often wish we could have a "soft no" or "advisory no" from CI

[DominicOram]

I often wish we could have a "soft no" or "advisory no" from CI

Nah, "soft no" will immediately get ignored and become "yes"

[callumforrester]

It's less an issue here, but for #633 I don't think the PVs being absent because of a power-down, or the device being unplugged for a service, should block merge.