In cases where curl perform returns an error but is actually a 400
level response, swupd needs to check curl info to see this. If the
info reveals a 400 level response, return the corresponding download
status error to prevent useless download retries.

Signed-off-by: William Douglas <[email protected]>

Signed-off-by: William Douglas <[email protected]>

The remove_files_in_manifest_from_fs function isn't used and was a
user of a rather dangerous recursive remove function. Get rid of it to
avoid potential confusion.

Signed-off-by: William Douglas <[email protected]>

Currently sys_rm_recursive was used in any instance of deleting swupd
content from the system (update, repair and bundle-remove). This can
cause user data loss when unkown files are in directories that swupd
is deleting.

To prevent this, this patch changes how deleting content in swupd
operates. Swupd content removal is now done with sys_rm and the return
value is checked in case the removal failed due to a directory that
still had files in it. When this specific failure occurs, the
directory is added to a new list for reprocessing removals as it is
expected once the rest of the deletes on the system occur the failures
will go away as the directories will be empty (these deletes are
processed in alphabetical reverse order so leaf directories are
processed first). If the removal fails again it is presumed the
contents of the directory are not files swupd knows about and as such
should be kept somewhere else.

For handling the retention of user data, directories (with only the
content unknown to swupd) are renamed (currently using a
.deleted.$timestamp. prefix of the old name) and stored at the same
directory level they were previously found with one exception. The
exception is for nested deleted content best illustrated with an
example:

/swupd-dir1/user-file1
/swupd-dir1/swupd-dir2/user-file2

When swupd tries to remove the /swupd-dir1 content, it will store the
user files as follows:

/.deleted.$timestamp1.swupd-dir1/user-file1
/.deleted.$timestamp1.swupd-dir1/.deleted.$timestamp1.swupd-dir2/user-file2

To demarcate what was part of swupd content vs user content.

Signed-off-by: William Douglas <[email protected]>

Signed-off-by: William Douglas <[email protected]>

The specific issue isn't impactful since the file is already scanned.

Signed-off-by: William Douglas <[email protected]>

Previous use of CURLINFO_CONTENT_LENGTH_DOWNLOAD is deprecated so
switch to the updated CURLINFO_CONTENT_LENGTH_DOWNLOAD_T API.

This change does not propagate the curl type used to the rest of
swupd-client but instead tries to use reasonable type casts for their
given purpose.

Signed-off-by: William Douglas <[email protected]>

systemctl reports that the timer file is missing now as a return code
4 so update the unknown start number.

Also with this change SWUPD_NO is no longer always returned so add a
new helper to check if a status is one of multiple options.

Signed-off-by: William Douglas <[email protected]>

Set response explicitly in case of curl_easy_getinfo error (though in
practice the response isn't modified and so program behavior is the
same as before this change).

Signed-off-by: William Douglas <[email protected]>

Previously, these messages were printed to STDOUT:
Overriding version and content URLs with...
Overriding content URL with...
Overriding version URL with...

But especially with --quiet, the output to STDOUT should be strictly the
requested data. So print these as warnings instead.

Eliminate some uses of wc -l that don't help. Take advantage of lines
array to count bundles.
Separate STDERR messages from $output and ${lines[@]} that are used for
bundles.

- Testing fixups
- Update to use CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
- Recursive delete handle user data gracefully
- Rework curl error checking

Signed-off-by: William Douglas <[email protected]>