We've found several times over the last few weeks that the OMs rail as we are trying to engage the AS DC centering loops, in preparation for engaging DRMI ASC.  I'm not sure why this has only started being a problem in the last few weeks and didn't bug us for the last few months.  I think it is happening if we try to turn on the DC centering servos a little too early.  

There is a checker for those loops to check for saturations because we've had this type of problem with the DC centering loops coming on too early in the distant past, but it was looking at the outputs of the DC servo filter banks.  This was the right thing to look at in the past, when we kept integrators in those filter banks.  However in the O2-O3 break we moved the integrators to the suspensions themselves, so now the servo filter bank outputs will always be near zero, and so will always pass the (old version of the) checker.  

I have added a few lines to also check the outputs of the OMs and RMs to see if the MASTER_OUTs are railed. If they are, then the engage_dc_centering states should clear the optics' histories and try again.  When doing this kind of clear history by hand, I've never had to do it more than once, so I'm fairly confident that this will be sufficient and we shouldn't have to worry about this again.  I've left in the old checking functionality too (although right now it'll always pass as okay) in case we ever decide to move the integrators back to the DC filter banks we won't get caught by this.

The following guardians will need to be reloaded: ISC_LOCK, ISC_DRMI, and ALIGN_IFO because they all use the ISC_library code that is now modified.  If there is a problem, one can comment out lines 170-174 in ISC_library.py and reload.

Also, I have added some clear histories and a short wait in ISC_DRMI's prep_for_drmi_asc state for INP1, since sometimes INP1 is sending out a kick and killing the DRMI lock.  I'd seen it several times, but Georgia put together the pattern that it only happens after we've done an initial alignment.  After she pointed that out, I think the problem is that since ISC_DRMI is already sitting in its down state, it doesn't go through down again as we get ready for main lock acquisition, so it doesn't redo the resets of INP1.  Sheila had already moved the gain setting to zero up in the prep_asc state, but because there wasn't a wait and the filters had some history in them, we were sending a short kick out before the gain gets all the way to zero.  Hopefully this will fix this problem, and we won't lose any more DRMI locks due to this.