[Craig, Jenne]

We have been seeing several times this week that when we try to find IR, we are not able to hold at a steady value.  The COMM loop in particular, but also the DIFF loop, seem like they can't hold the beatnotes to a close enough frequency. 

Just now, Craig noticed that the PSL FSS common gain was at a low value of -10, when it should be +20.  Looking at the data, it has been at -10 since 4 Sept 2018 at about 05:30:00 UTC.

Looking at the PSL_FSS guardian, the FSS_OSCILLATING state checked if the FSS was oscillating.  If oscillating, turn the FSS common gain down to -10. When it's not oscillating, pause, then turn the gain back to +20 and return True.  What it didn't check was if the FSS was locked.  So, we were in the FSS_OSCILLATING state with the gain at -10.  The FSS unlocked and so reported that the loop wasn't oscillating.  But, since we had requested a different state of the PSL_FSS guardian at that same time (which the ISC_LOCK guardian does in the DOWN state), it jumped out of FSS_OSCILLATING and went to the new state, without the pause and increase gain.  So, we've probably never seen this before because it was a bit of a rare case that the FSS was oscillating then lost lock at almost exactly the same time that we requested a different state. 

I have added a check to the FSS_OSCILLATING state that the FSS be locked as well as not oscillating in order to continue.  Hopefully this will prevent this from happening again.  Also, yet another thing that if we were keeping up with SDF (really hard to do while things are so in flux during commissioning) we would likely have found.  Oh well.