Persistence of "update available" status is unclear

We were debugging a problem noticed by end users when auto-downloading is disabled. system-settings issues a CheckForUpdate() which indicates that an update is available, but since auto-download is disabled, the update is not downloaded immediately. The user waits long enough before hitting the Download button in the u/i that system-image-dbus exits (there's a default 10m timeout but of course the process can be -TERM/HUP'd).

Now after this occurs, the user clicks on Download and expects the update to be downloaded but this doesn't happen. It's because when s-i-d gets re-activated, the state about whether an update is available or not, is *not* persistent across process invocation. Thus s-i-d returns a status that says no update is available.

Note that this status *cannot* by specification be persisted across s-i-d invocation. There are two strategies the s-s client can employ:

* Always call CheckForUpdate before DownloadUpdate (or perhaps only if auto_download=0 though this might be racy). If the s-i-d process has not exited, an UpdateAvailableStatus signal will be issued immediately. If the s-i-d process has exited, it will of course re-check for an update and proceed as normal from there. It is at worst harmless to call CheckForUpdate first.

* Always call the Information() method. This is a synchronous method that returns -1 for the target_build_number if no update is known. Thus, you know if you get a -1 that the process has exited and the CheckForUpdate needs to be called first.

I will update the manpage with the relevant information.