Refactor scheduling logic

[smallketchup82]

https://github.com/smallketchup82/ketchupbot-updater/blob/71b819c02cf911dbf28538a7dc13cd10908756f4/ketchupbot-updater/Program.cs#L139-L144

[smallketchup82]

@CornHusker89 do you think this is still needed, or are we fine?

to make it more clear as to what i want to accomplish here, i was thinking it'd be better to abstract all of the logic out into "jobs" with quartz. so that, for example, if the user decides to do a single mass ship update, it gets run in a job and scheduled for the closest minute. in the same example, if a user decides to do scheduled mass ship updates, we can reuse the same job but for every ship.

this removes code duplication & makes full use of quartz. but it comes with the added issue of users probably having to wait a bit for it to run, and also probably adds a bit of complexity.

do you think we should just leave it as is, or should we migrate everything out into jobs?

[CornHusker89]

if we can make it run in the next 5 seconds or something then sure but otherwise it would be a bit of a pain. But then again, 1 minute isn't that bad, so low key it doesn't really matter

[smallketchup82]

i'll write up a test implementation.

i don't know what to make of the added complexity but keeping things monolithic feels good. just a gut feeling. so i'll try to push this forwards.

[smallketchup82]

@CornHusker89 ok actually, im a little hesitant to work on this. if #56 ends up happening, the effort spent here would effectively be wasted

i think ill leave this stale