Librarian client should timeout faster

Actually, if you look at bug 140818, you'll notice that 1 second is actually not enough. Part of the problem may be bug 140817, but part of it is that the database just can't be counted on to respond in less than one second.

Assigning to Francis, but I'm curious: what's the default timeout set to?

There is no default timeout (None), which means to wait indefinately.

This could be fixed easily now by using canonical.lazr.timeout.urlfetch to retrieve files. We can use the with_timeout decorator for the other requests that aren't using urlopen() to talk to the librarian.

https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1665EA1853

I think 1 second is tonnes of time: if the DB can't answer a simple lookup as this in 1 second, given our scaled out infrastructure, we are going to find delivering high responsiveness terribly hard.

https://bugs.edge.launchpad.net/launchpad-foundations/+bug/140817 may be stale, and even if it isn't, we don't want server threads hanging about for 20 minutes when using the librarian.

There are two parts to this I think:
 - extend the client code to accept a per-connection timeout value (rather than changing a global)
 - pass down to the client the *remaining appserver timeout allowance* automatically. That way, a fresh request has the maximum possible timeout, and one at the end of a slow transaction has a shorter timeout.

Also shows up as
 SoftRequestTimeout: <security proxied canonical.launchpad.browser.librarian.StreamOrRedirectLibraryFileAliasView instance at 0xcb0ef90>

    Traceback (most recent call last):
SoftRequestTimeout: <security proxied canonical.launchpad.browser.librarian.StreamOrRedirectLibraryFileAliasView instance at 0xcb0ef90>

importance/milestone carried over from the duplicate.

StreamOrRedirect view is no longer needed; MP diffs are size capped so shouldn't trigger this - can reevaluate priority if we find this is implicated in oopses going forward.