[supervisor] Add patch to prevent 'supervisorctl start' command from hanging if system time has rolled backward

[jleveque]

If the system time rolls backwards after supervisorctl start <process_name> has been called but while the process is still in the STARTING state (i.e., it has not yet entered the RUNNING state), then, depending on how far backward the system time has rolled, the supervisorctl start <process_name> command can hang a very long time waiting for the system time to reach self.laststart + startsecs.

This patch creates a temporary workaround to mitigate this issue by resetting self.laststart to the current system time if it is ever determined that the system time has rolled backward.

I have opened an issue on the Supervisor GitHub repo (Supervisor/supervisor#1043). Once the Supervisor folks merge an official solution, I will remove this patch and pull in the latest upstream changes.

[lguohan]

I am ok with this pariticular fix. however, I think the time travel can cause other problems in the code.

i checked the supervisord code, it looks like there are other places that save the current time to a value and use it later, like self.delay, it could also have the same problem in the back-off process.

if you are in the backoff state, and the system clock moved backward, then you need wait for a long time to catch up and the process won't restart for a long time.

another example is last_dispatch.

this does not sound like a trivial problem. I also see there are some unittest added. I think we need to fix all the problems I see above and add unit test code and add unit test code.

[lguohan]

need a more comprehensive fix and unit test code