[packagekit] New functionality: using idle bandwidth

[Richard Hughes]

I've just pushed two patches to git master which set the use_idle flag
to TRUE for GetUpdates. In the second of these commits I've made the
yum backend respect this, and use the TCP Low Priority congestion
control algorithm, which is obviously Linux specific.

It's a quick hack to basically not have the initial login GetUpdates
take all your available bandwidth and not starve other downloads or
things like firefox. Of course, there are downsides, see
PackageKit.conf for the verbage:

# If certain operations should be done using IDLE bandwidth
#
# TCP Low Priority is a congestion control algorithm included in the kernel.
# Connections using this algorithm will use only idle bandwidth. In other words,
# it is a self-tuning TCP stack. Setting this to FALSE will mean that the check
# for updates happens more quickly, at the expense of other network applications
# such as firefox and other file downloaders.
#
# If the user is running the network at 100% for extended periods of time, then
# the update check may be starved and take a very long time to complete. In this
# rare case, this setting should be set to FALSE.
#
# By also setting this setting to TRUE makes the possibility of a environment
# mismatch much higher for a spawned backend. This will make switching from idle
# operations (such as GetUpdates) and full speed operations (such as
# InstallPackages) take longer. If this is a concern, then set this to FALSE.
#
# default=true
UseIdleBandwidth=true

I've defaulted this to true for now, but we might revert to false for
the release next week.

This also triggers a more interesting problem. When the GetUpdates
method gets called for me once a day, it probably should use idle
bandwidth, and not do interactive stuff like importing gpg keys. If
I'm doing GetUpdates during the Update Software UI, then I want it to
happen straight away and bother me with GPG keys. It's the same
problem when I'm updating interactively and when idle, and is
something Sebastian touched on last week with the debconf stuff.

Ideally we need to give the daemon (and thus the backend) more context
than just "give me the update list with this filter".

At the moment we already give out-of-band information  (i.e.
supplemental to the transaction) in the SetLocale() method as part of
the transaction dance. We could deprecate SetLocale() and introduce a
SetTransactionHints() method (better name welcome) that allows
freeform hints to be sent, e.g.
"interactive=false;idle=true;locale=en_GB.utf8" with the daemon
picking good defaults if the method is not sent or a parameter is
missing. This would mean that we wouldn't have to break public API and
in the common case everything just worked as before.

This solution would also allow the apt and aptcc backends to use
debconf for interactive tasks, and use the default for interactive
tasks. I don't believe caller-active is suitable for this decision as
transactions derived from gpk-update-icon will always be active as the
process is running in the background.

Comments, suggestions and criticisms welcome.

Richard.