Re-implementation using WorkManager

[JessHolle]

Google is pressuring those using services for reliable uploads (as this library does) to use WorkManager (or another solution, but primarily WorkManager).

As best I can tell the reason they are doing this is that each work request is registered along with the device state constraints required to execute the work (e.g. having an available network in this case). By doing so, various apps do not need to stay in memory waiting for these conditions but instead can be restarted when those conditions are met.

So apart from getting Google off our backs there does appear to be a benefit to the end user here.

(I have a very similar library except it is a combination of a guaranteed and expedited delivery event stream with chunking/batching upon any send backlog and event attachment files. Applying WorkManager properly seems a bit trickier in that case...)

[trix0]

And another reason for this to be a great change would be Unable to start service net.gotev.uploadservice.UploadService@594ea38 with null: android.app.ForegroundServiceStartNotAllowedException: Service.startForeground() not allowed due to mAllowStartForeground false: service makeable.Intempus/net.gotev.uploadservice.UploadService Where Google again broke the foreground services. https://issuetracker.google.com/issues/307329994

[gotev]

Started some reasoning back in 2021 about this, worth joining the two issues into one: #610