LS240 Acquisition Crashed without Killing Agent

[kmharrington]

We had one of our LS240s crashbut the agent stayed up and showed now errors. Here's a cutout of the logs.

Restarting the agent got readout back, but an OCS status monitor wouldn't have caught it.

2021-05-10T15:42:36+0000 acq:1 Status is now "running".
2021-05-11T16:56:55+0000 acq:1 Crash in thread: [Failure instance: Traceback: <class 'TimeoutError'>: Device timed out
/usr/lib/python3.6/threading.py:916:_bootstrap_inner
/usr/lib/python3.6/threading.py:864:run
/usr/local/lib/python3.6/dist-packages/twisted/_threads/_threadworker.py:46:work
/usr/local/lib/python3.6/dist-packages/twisted/_threads/_team.py:190:doWork
--- <exception caught here> ---
/usr/local/lib/python3.6/dist-packages/twisted/python/threadpool.py:250:inContext
/usr/local/lib/python3.6/dist-packages/twisted/python/threadpool.py:266:<lambda>
/usr/local/lib/python3.6/dist-packages/twisted/python/context.py:122:callWithContext
/usr/local/lib/python3.6/dist-packages/twisted/python/context.py:85:callWithContext
LS240_agent.py:250:start_acq
/app/socs/socs/Lakeshore/Lakeshore240.py:280:get_reading
/app/socs/socs/Lakeshore/Lakeshore240.py:114:msg
]
2021-05-11T16:56:55+0000 acq:1 Status is now "done".

[jlashner]

Though not exactly the same, I think this is similar enough to #7 and #128. I think it just boils down to how we want to handle disconnects. I think the acq function should probably attempt to re-initialize the ls240 module before crashing, and then if that doesn't work just killing the reactor entirely instead of leaving the agent running.