Per arma's comments in bug1138

tor_assert(!conn->_base.purpose == DIR_PURPOSE_FETCH_EXTRAINFO)
!=
tor_assert(conn->_base.purpose != DIR_PURPOSE_FETCH_EXTRAINFO)
!!

 - Move checks for extra_info to callers
 - Change argument name from failed to descs
 - Use strlen("fp/") instead of a magic number
 - I passed on the suggestion to rename functions from *_failed() to
   *_handle_failure(). There are a lot of these so for now just follow
   the house style.

 requests to authorities fail due to a network error.

Bug#1138
"When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority
is set, Tor will go to the authority first and look up the bridge by
fingerprint. If the bridge authority is filtered, Tor will never notice that
the bridge authority lookup failed. So it will never fall back."

Add connection_dir_bridge_routerdesc_failed(), a function for unpacking
the bridge information from a failed request, and ensure
connection_dir_request_failed() calls it if the failed request
was for a bridge descriptor.

Test:

1. for ip in `grep -iR 'router ' cached-descriptors|cut -d ' ' -f 3`;
do sudo iptables -A OUTPUT -p tcp -d $ip -j DROP; done
2. remove all files from user tor directory
3. Put the following in torrc:

UseBridges 1
UpdateBridgesFromAuthority 1
Bridge 85.108.88.19:443 7E1B28DB47C175392A0E8E4A287C7CB8686575B7

4. Launch tor - it should fall back to downloading descriptors
   directly from the bridge.

Initial patch reviewed and corrected by mingw-san.

These circuits stick around much longer than others on the server side for
performance reasons. Their lifetime is controlled by the client.