refresh_possible_transports should catch more exceptions

[Max Bowsher]

Traceback (most recent call last):
  File "/srv/package-import.canonical.com/new/scripts/import_package.py", line 1155, in <module>
    only_before=options.only_before))
  File "/srv/package-import.canonical.com/new/scripts/import_package.py", line 1071, in main
    bstore, push, possible_transports=possible_transports)
  File "/srv/package-import.canonical.com/new/scripts/import_package.py", line 606, in import_package
    possible_transports=possible_transports)
  File "/srv/package-import.canonical.com/new/scripts/import_package.py", line 414, in make_db_set
    icommon.refresh_possible_transports(possible_transports)
  File "/srv/package-import.canonical.com/new/scripts/udd/icommon.py", line 1783, in refresh_possible_transports
    t.has('file-that-does-not-exist')
  File "/var/lib/python-support/python2.5/bzrlib/transport/http/_pycurl.py", line 157, in has
    self._curl_perform(curl, header)
  File "/var/lib/python-support/python2.5/bzrlib/transport/http/_pycurl.py", line 388, in _curl_perform
    'curl connection error (%s)\non %s' % (e[1], url))
bzrlib.errors.ConnectionError: Connection error: curl connection error (Peer closed the TLS connection)
on https://launchpadlibrarian.net/59057562/file-that-does-not-exist

[Max Bowsher (maxb)]

I've seen this a few times as a spurious failure. Most recently from the qbittorrent import.

[Vincent Ladeuil (vila)]

The root cause is that refresh_possible_transports only catch socket.error while bzrlib may have raise other higer level exceptions which also represent a connection loss (in which case the transport is not reusable and should just be silently discarded).

[Vincent Ladeuil (vila)]

I encountered the same issue while re-trying the chromium-browser import which seems fine otherwise (but takes 24 hours or more to finish).