when creating a full backup, the task is still running and the database
dump which is part of the backup, still says it is still running.
during restore, we mark the taskId as completed. detection of the task
is using the siteId in config (when restoring via backup config) or
just blindly setting the last backup task as completed (in manual form fill).
previously, we had a singleton 'main' flag to indicate a site can
be used for updates. with this new approach, we can get rid of the
'primary' concept. each site can be used for updates or not.
1. add setup, teardown hooks
2. move the managed mount setup and teardown to filesystem backend
3. remove this vague storage.js
we should convert storageApi into a real object, so we don't have to
keep passing apiConfig around
format is part of the backup target
in the future, if we want per-app format or schedule, we can add this
separately to the apps table itself. the full box backup can ignore
apps with a set backup target and use the latest backup (like an errored app).
the nice thing is restore will work correctly.
what's important:
* if task code ran, it exits with 0. this code is regardless of (error, result)
* when it exited cleanly, we will get the values from the database
* if task timed out, the box code kills it and it has a flag tracking timedOut. we can
ignore exit code in this case.
* if task code was stopped, box code will send SIGTERM which ideally it will handle and end with 70.
* if task code crashed and it caught the exception, it will return 50
* if task code crashed and node nuked us, it will exit with 1
* if task code was killed with some unhandleabe signal, taskworker.sh will return the signal (9=SIGKILL)
Girish Ramakrishnan