Snap installs don't reliably resume on network flakiness

[Peter Sabaini]

When, during the download phase of `snap install`, networks get interrupted snappy seems unreliable on picking up networks.

I can reproduce this fairly consistently by adding an iptables DROP rule for tcp:443 during download, sleep for a period of time and then removing it again.

For instance in a fresh bionic container with snapd installed:

root@juju-daaea6-zaza-d18e56273374-2:~# snap list
Name Version Rev Tracking Publisher Notes
core18 20201210 1944 latest/stable canonical✓ base
snapd 2.48.2 10707 latest/stable canonical✓ snapd
root@juju-daaea6-zaza-d18e56273374-2:~# DROP_TIME=100 snap install chromium --classic & ( sleep 4 ; iptables -I OUTPUT -p tcp --dport 80 -j DROP ; iptables -I OUTPUT -p tcp --dport 443 -j DROP ; sleep $DROP_TIME ; iptables -D OUTPUT -p tcp --dport 80 -j DROP ; iptables -D OUTPUT -p tcp --dport 443 -j DROP )

For short DROP_TIME (<10) snappy would resume downloading after the DROP rule was removed, for DROP_TIME=100 it would hang indefinitely.

[Paweł Stołowski (stolowski)]

I believe this can be considered a duplicate of https://bugs.launchpad.net/snappy/+bug/1912615