Fix [#595}: Scheduled downtime bugs

[tsadpbb]

Closes #595

There was a lot of confusion around making sure events are not "double scheduled" resulting in the downtime just starting and ending immediately. So I got rid of it and moved the start and end logic into separate functions. This increases some repeated code but I think that it's worth it.

I also added refactored and added to the register_downtime function, so now a triggered downtime will start if the triggering downtime is already on and a flex downtime will start if the host/service is already down

To Test

Play with downtimes. Add a variety of different downtimes under different conditions. Make sure that behavior is expected.

Issues still present

• I don't like how the downtime expiring sends a downtime end notification.
• When a downtime expires, events that would have been triggered by it are not deleted
• Instead of just not scheduling a downtime if the time is passed the downtime end, it'll just immediately scheduled a downtime end

[aaronagios]

@ericloyd any thoughts here?

[ericloyd]

Can't ask me after 5pm on a Friday! 😆

I'll try to take a look tomorrow. Thanks!!

[aaronagios]

how about after 4pm on a Monday @ericloyd ?

[ericloyd]

See, @aaronagios, that it wasn't just 4pm on a Monday, it was 4pm on Veterans Day. Since I work for a service-disabled veteran owned company, it's an important day for us and I don't even open my email.

So, having taken a look this morning, I'm not sure what you're expecting from me on this. If it does what it says it does, then it's an improvement. I share Dylan's three bullet point concerns, but I'm less concerned about the first - unless he means that downtime expiration that never triggered sends a downtime end notification, which would be confusing.

Did a quick trip through the code and I see nothing that looks like it breaks core (get it?) functionality. Triggered downtime has always been a tough one and we generally don't recommend it for our customers. Our customers tend to be larger organizations with well-defined IT support however, and they do their downtime in scheduled chunks so it's easier. Triggered downtime never really made sense to me, personally, since you could just use a host/servicegroup and schedule flexible donwtime for the group instead of a bunch of triggers that may or may not fire.

But I digress.

I'd be okay with this PR being moved into production code. Thanks for asking!