feat: add db uptime notification support

[iloveitaly]

Pairs well with something like Uptime Kuma's push notifications
to ensure this service doesn't fail without us knowing about it.

[josegonzalez]

I feel like this sort of functionality happens better at the cron scheduler level. So for instance:

* 0 * * * command && curl whatever

Vs happening here. Thoughts?

[iloveitaly]

Ah, yeah, I actually like that better! The scheduler utils right now don't allow for additional options though, right?

May not make sense for this to be a first-class feature, but it's unclear exactly where to put the manual cron entry to mimic with the postgres plugin does. What's the best way to do that?

[josegonzalez]

There's some logic around how we expose cron entries for the cron-entries plugin.

$SCHEDULE;$FULL_COMMAND;$ARBITRARY_DATA

ATM the $ARBITRARY_DATA is treated as a log-path, but honestly we probably want something more structured? Basically its either a string path or its a json object (no newlines of course) with the following setup:

{
    "log-path": "/var/log/dokku/command-output.log"
    "post-success-url": "http://example.com/ping"
}

I'd prefer to not expose any arbitrary command as that could lead to arbitrary code execution.

With this change, the output of cron-entries should be parsed - with the url validated as a proper url - and the new data added to the thing that gets templated out. Then we'd call the url like so:

* 0 * * * command && curl -fsS -m 10 --retry 5 -o /dev/null "http://example.com/ping"

The logic for parsing is around here, and we'd want to update the cron.CronTask struct to hold the log-path (which is ignored? so maybe we just actually handle it all as a json dict?) and the post-success-url, and then template them out as appropriate.

We could also in theory add support for those keys to regular cron tasks, but I think starting with adding system ones would be good, and then we can add support for configuring those keys to the various datastore plugins.