chore: Refactor cronjob controller

[hmalik88]

closes #2954

Refactors the CronjobController logic to deduplicate logic being used across cronjobs and background events.

[codecov]

Codecov Report

Attention: Patch coverage is 93.54839% with 2 lines in your changes missing coverage. Please review.

Project coverage is 94.82%. Comparing base (78dd810) to head (f7f4cb5).

Files with missing lines	Patch %	Lines
...snaps-controllers/src/cronjob/CronjobController.ts	93.54%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3029      +/-   ##
==========================================
+ Coverage   94.80%   94.82%   +0.02%     
==========================================
  Files         503      503              
  Lines       10996    11000       +4     
  Branches     1685     1687       +2     
==========================================
+ Hits        10425    10431       +6     
+ Misses        571      569       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[FrederikBolding]

I haven't reviewed this in detail. but generally when I proposed we refactor the CronjobController, the main goal I had in mind was to unify the logic used to manage background events and cronjobs.

We currently treat these as entirely separate entities, but I don't think they need to be. My general thought was that we should investigate treating them as one entity with the only variation being non-recurring versus recurring cronjobs (or background events - no strong opinion on the name).

I had intended for the referenced ticket to be to investigate ways to achieve this.

[hmalik88]

This PR unifies some logic, but I inherently found it hard to make a mental model of both being the same thing because the term non-recurring cronjob in of itself is an oxymoron. Maybe there's a better term to encompass both things. One divergence is that we fetch the cron jobs every time from the manifest, maybe if we can fetch once and unify the state then some of the other logic itself can be refactored. We can keep the original ticket open, I think this is an improvement nonetheless.