Enable restart on failure and optionally exponential backoff

[Nick1296]

I just implemented part of the changes we were discussing in #45.
I figured out that the stuff I was saying on the WantedBy= option does not make sense, since we need the service to start to have flatpaks installed and making the Wantedby= option empty prevents that, even on rebuilds. However, I only used the setup in testing-base/ to verify this.

I still wanted to have slightly better resilience to network failures, and the current solution goes hand in hand with the need of having the service started on each activation.
My take on the problem makes the flatpak-managed-install.service automatically restart on failure with a customizable delay. The user has also the option to enable an exponential backoff strategy, with a customizable number of steps and maximum restart delay.

This has been implemented using the systemd.service(5) Restart=, RestartSec=, RestartSteps= and RestartMaxDelaySec= options.

So maybe this plus #110 could be a good solution for the issue mentioned in #45.

Let me know if you have any corrections or opinions, and thinks for considering my contribution!

[gmodena]

Hey @Nick1296,

Thanks for this. This is a very much welcome improvement for reliability, and I like how you managed to piggy backed on systemd.

I'll test your change on a VM and on my daily driver before merging, but the approach LGTM.

However, I only used the setup in testing-base/ to verify this.

Terrific! This kind of implementation is hard to test, but I think it will be fine to use main as a canary before the next release. The change only affects retries on failure, so I don't expect any regressions to spill over into the happy path.

I figured out that the stuff I was saying on the WantedBy= option does not make sense, since we need the service to start to have flatpaks installed and making the Wantedby= option empty prevents that, even on rebuilds

Thanks for clarifying. I was looking into the references you left on the gituhub issue, and did not fully understand how the dep chain would resolve :).