Migrate to mkosi + sysupdate - #809

This is more elegant than #808, and builds out the mkosi/sysupdate method from #793 that fully supports ubuntu already. In comparison to my bootc suggestion, this:

• Build: mkosi build --profile=sysupdate Create disk image (currently .raw but could be a fake .iso).
• Install: rsync mkosi.output/elementary.raw https://r2.cloudflarestorage.com/installer/x86.iso Copy the image to the download link, so users can download it and write to a USB drive. Live boot session would need to copy this image to disk. Installer would need to be adapted.
• Update: rsync mkosi.output/* https://r2.cloudflarestorage.com/updates Push image to any static host so all existing ElementaryOS installs can run updatectl update (settings app would need to be adapted). This checks a static folder at ie. updates.elementary.io (currently set to 10.0.2.2:7676 for testing), downloads anything newer than the currently-booted IMAGE_VERSION, drops it into the inactive A/B slot, and reboots into it on next boot. Even over major versions like 8=>9=>10.

@danirabbit what's the best way to land this? This PR currently replaces the old stuff, but I'm guessing some the 8.1 stable jobs might be run in parallel with the 9.0 sysupdate jobs until 8.1 reaches EOL?

Edit: My proposal, not speaking for @jumpyvi here:

• When ready to merge, make current os/main branch into archive and keep running the 8.1 stable jobs off of that archive branch.
• This becomes main, and starts building the sysupdate isos and updates.

OK so going back on my above suggestions, how about we keep sysupdate on a branch, and add a 4th job on a sysupdate branch then:

• daily-8.1 (main branch)
• daily-9.0 (main branch)
• stable-8.1 (main branch)
• image-9.0 (sysupdate branch this can be a manual kick-off, and not advertised until there's delta updates?)

* image-9.0 (sysupdate branch this can be a manual kick-off, and not advertised until there's delta updates?)

We don't know when/if systemd will choose to implement this.

idk if there is any other solutions

systemd/systemd#28227

For S3 compatible storage I would recommend Cloudflare R2. We already use Cloudflare and there is no bandwidth billing there, only storage and action costs.

Thank you! Looks like we were holding it wrong: cost won’t be a problem at 0ドル.60 for 10,000 users downloading a 4gb image once a week on Cloudflare R2 (50 gb, 4 writes per mo, 70% egress, 40,000 reads per mo) - thank you @lewisgoddard .

OK so maybe @jumpyvi we don't optimize for transmission size yet for now then, and optimize for deltas later as sysupdate matures - other projects will have this problem too.

@jumpyvi got updates working (hosted on a temporary CDN), @jumpyvi has also booted the .raw off of a usb stick (I don't have one that's big enough).

Finally, an initial job has been added @danirabbit - edited upload.py to upload to Cloudflare R2

Sorry for my late review, I will take a look at this again when getting back home today.